Just wanted to slightly clarify this. This advice is not specific to ASP.NET. It's a coding philosophy. Good error handling can't be taken care of by using passive top-level exception handlers alone. Likewise, good error handling can't be taken care of with low-level exception handlers that respond to specific conditions that you've seen before. You need both approaches to produce robust code. With both approaches in place, over time the number of low-level handlers will increase as your code is exposed to more conditions that get logged in the top-level filter.
-----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill Sent: Wednesday, September 21, 2005 11:15 AM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] What are the errors and exceptions that we should log in ASP.Net At 05:49 AM 9/21/2005, Manoj Aggarwal wrote (in part) >Dear Friends, > >I would like to know all errors and exceptions that we should log in >asp.net applications. I am using xml file for logging errors. I want to >know the exceptions that are most likely to occur in the application >and we should log them down. > >I believe that we should not catch all acceptions from >ApplicationException class. Rather we should catch specified exceptions. >[snip] I very much don't agree. Any exception that is not explicitly caught indicates a failure to process the user's request, so the "global" exception handler should log everything. (It should even log exceptions that aren't ApplicationExceptions, for the same reason.) The code that (for example) opens a database connection should handle a failure itself, so the global exception handler would normally not see it. The code that verifies the user's login name and password won't raise an exception if it's not found; it will return a valid page to the user (saying that her name/password was not found). Another reason not to look for specific exceptions is that an update to any component you use could make possible a new exception. It's exactly the totally unexpected exceptions that you most need to know about! In other words, you might not want to log the exceptions that mean specific things like "the database connection stopped working" (because you presumably know when the database is down), but you definitely want to log anything that was caused by any exception that you've not specifically determined is NOT caused by a bug in your code. If the info that you log doesn't help you find and fix the problems, then you should either log very minimal information, or enhance your logging so that it provides what you need to figure out what caused the problem. J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
