How to handle an exception within exception handling code?

I've got some code in my开发者_如何学Python web app to deal with unhandled exceptions - it hands off to a fancy custom error page which logs the details. But what if there's an unhandled exception within the custom error page?

I can detect this condition in my general exception handler by checking to see if Request.CurrentExecutionFilePath equals my custom error page, and thus take steps to avoid the loop. But any ideas what these steps should be - fall back to the yellow screen of death, hand off to a static custom error page?

Or should I just wrap my custom error page code in a try {...} catch {} and stop worrying about it?

---

I would use .nets custom errors framework and set a static html file as the target for a 500 error. Its a bad idea to have a custom 500 page do anything that could fail as its likely any io commands have failed already (such as database or file access).

Its always best to keep custom 500 pages as simple html files and do all exception logging via the Application_Error event in the applications global.asax, allow the exception to be thrown then use the .net custom exception handler serve up your custom page.

EDIT: Here is a related article on the pattern described above. Note the only difference is that I would use a static html 500 page

http://devhood.com/tutorials/tutorial_details.aspx?tutorial_id=237

---

Wrap your custom error code page in a try{...} catch{doSomethingThatCannotPossiblyFail()} construct.

---

Quite honestly it all depends on the volatility of your logging mechanism, and how badly you want to log each error. There is always going to be the possibility that your logging will fail, because it is based on something external to your program working (e.g. Database being available, having access to the log file, event log not being full etc.). You should definitely wrap you logging in a try catch block if for no other reason to prevent a huge nasty error displaying to the user.

Personally, I would put in multiple paths of logging. The first one maybe to the database (although I personally don't like logging errors to the db, I prefer log files), and a second to the event log along with trying to send an email stating something is wrong. There is no sure fire way to say my logging to an external source will absolutely never fail, but you can minimize that possibility, and make sure that no matter what happens the end user doesn't see a catastrophic failure error.