Professional ASP.NET 3.5 AJAX

5.3. Error Handling

Inevitably something happens and an exception is thrown. It might be a timeout accessing a remote service or an offline database in the middle tier. You may not have accounted correctly for all of the edge cases that can occur when processing user input. Adding asynchronous callbacks to more of the ASP.NET application provides additional challenges in handling errors in a user-friendly way.

5.3.1. Allowing Custom Errors

If your user encounters an error with your ASP.NET application, you may be taking advantage of ASP.NET custom errors to redirect the user. You can provide a page with a look and feel consistent with the rest of the site that provides something more user-friendly than a developer-focused error message. At the same time, you might log some information using tracing functionality so that you are aware of the frequency with which users are encountering errors. Then you can follow up to try and improve the experience and prevent the error from occurring in the future.

With asynchronous postbacks and partial rendering, an exception can go back to the script that initiated the callback, and the default behavior is to throw a JavaScript exception. This happens even if you have custom errors enabled for your application. Part of the reason that the default behavior is not to follow redirects is the potential to navigate away from a page where a user has invested time updating a state in stages without navigating between pages. Your objective is to keep ...