I would have to agree: log all exceptions. If you know what exceptions you can not bother logging at a top-level handler, then you have a perfect program that shouln't require any logging.
http://www.peterRitchie.com/ On Wed, 21 Sep 2005 10:21:53 -0500, Marc Brooks <[EMAIL PROTECTED]> wrote: > I would like to know all errors and exceptions that we should log in asp.net > applications. Good luck with that. There IS no complete list, as any control you use, or another developer's code could throw any exception they wish to create. > 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. You should log ALL exceptions other than ThreadAbortException (in an ASP.Net application, since that gets thrown when doing a Response.Redirect(xxx, true); > I believe that we should not catch all acceptions from ApplicationException > class. In ASP.Net, you should catch at the top-level of your application System.Exception and log it, then redirect to a user-friendly error page. This is usually done in the Application_Error handler in Global.aspx.cs file like this: protected void Application_Error(Object sender, EventArgs e) { try { Exception ex = Server.GetLastError(); // if the outer exception is just a HTTP run time wrapper, dive down a layer. while (ex as System.Web.HttpUnhandledException != null) { ex = ex.InnerException; } // we ignore all ThreadAbortExceptions, the application is just being recycled OR the // page was redirected. if (ex as ThreadAbortException == null) { LogManager.Publish(ex); } Server.ClearError(); Server.Transfer("~/Scripts/ApplicationError.aspx", false); } catch { // Ignore the error here since we are already in error trapping mode. } } Your mileage may vary :) > Rather we should catch specified exceptions. Other than the top-level logger given above, you should catch ONLY the exceptions you KNOW how to handle. We can't possibly know which ones you can handle or not because it's a very situation-specific issue. For example, is it okay in your application to be missing a configuration file, because you are going to default the configuration? Then you can catch the FileNotFound exception and NO OTHER and do the right thing... > So in the context of things, please let me know the errors and exceptions > that I should look for in my application, so that I am able to create a > error free application. Unfortunately, I doubt you are working in Java. We can't give you the exhaustive list of exceptions that might be thrown (and indeed, in Java it's not even completely clear what the list might be). The simple list of exceptions isn't enough to write error free applications. You have to know _what_ to do in each situation when an error occurs. If you aren't writing mission-critical software, it might be enough to just log the error and redirect the user, but that isn't an error free application, it's an error tolerate application. I refer you back to the first thread you started, it's got links and discussion you obviously didn't get the full value from. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
