What is the accepted way to handle errors during async postbacks in ASP.NET?

We have an ASP.NET page which uses an update panel for partial page postbacks. On the server side, the postback performs some database work and updates several UI elements. The database code is all contained in several transactions, so the state will still be consistent if an exception is thrown. We're working on some error handling code now, and my first thought was to log the exception thrown, reload the last consistent UI state, and show some sort of modal popup or other ui element with a brief error message for the user (this is an intranet page, so we're automatically notified of the bug, and the users know where to find us :)

Is this a good idea? What alternatives would be better for our end users?


I would log the exception and redirect to an error page ("Sorry, we screwed up").

In most cases, I don't think it's worth complicated recovery (last consistent state). In particular cases, it may be, but mostly, not.

Note that the standard mechanisms will do most of this for you. Designate an error page, and ASP.NET will redirect there on an error. Also, unhandled exceptions will be logged by ASP.NET Health Monitoring, in the event log.

Need Your Help

phpprorobid issue: setting up live is messing a lot

php .htaccess xampp wampserver zend-optimizer

I have a live project developed in "phpprobid" auction software and i have to transfer it on local, I downloaded it and set it up on my xampp 1.7.4 which has php 5.3.5 but at start it said install ...

C: uint16_t subtraction behavior in gcc

c gcc unsigned stdint

I'm trying to subtract two unsigned ints and compare the result to a signed int (or a literal). When using unsigned int types the behavior is as expected. When using uint16_t (from stdint.h) type...