I agree 100%. Thanks for clarifying. At 11:19 AM 9/21/2005, Owen Cunningham wrote >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
J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
