"Good" ASP.net Stack Traces in Release Configuration or how to get the offending code

Question

If I have an application running on ASP.net and I have debug and stacktrace enabled in web.config, I get a really nice Error Screen telling me exactly which code caused the error.

Sadly on a live system where debug is set to false, the yellow screen of death is quite unhelpful, even with stack trace enabled, it does not show the line where the error happened (which seems obvious since there should be no debug information).

I just wonder if there is a way to get a good information about an error without having to enable debug=true in the web.config file. It does not have to be an improvement on the Yellow Screen, I can also wrap the code that I suspect to offend in a try..catch block, but then inside the catch block, is there a way to get to the actual code that caused the error?

As you may suspect, this is for a situation where an error only occurs in production and no remote debugger is available :(

Edit: This is concerning "normal" exception, like System.ArgumentOutOfRangeException. Littering the code with logging is something I would like to avoid if there is a better way just to get more information where the Exception actually occured.

Answer 1

Can you retro-fit some sort of application error logging such as Log4Net or ASP.NET Health Monitoring?

Answer 2

The first thing I'd do when faced with this would be to add a global exception handler to the global.asax, for example:

    protected void Application_Error(object sender, EventArgs e)
    {
        Exception ex = Server.GetLastError();
        Log.WriteException(ex);   // this is your code
    }

You can also do something like this on the page level, but I think you're better off doing it at the application level. When you write out the exception to the log you can also write out more information to help you recreate the error, such as the request parameters or session information.

Another good practice is add a section like this to your web.config:

  <customErrors mode="On" defaultRedirect="error.html">
    <error statusCode="500" redirect="500.aspx"/>
    <error statusCode="404" redirect="404.aspx"/>
    <error statusCode="403" redirect="403.aspx"/>
  </customErrors>

This will show the error.html on all unknown errors, and show the appropriate pages you've defined for some specific errors where you can give the user more information as to how to resolve the error or help them find what they're looking for.

Error handling in asp.net is a pretty big topic, but this should be a good starting point.

Answer 3

Without littering your code with logging, I think the way to go about this is to refactor your code into smaller methods. Sounds like you have a large method that does a lot of things and the exception could be happening in a number of places within that method. This has happened to me before and the way I've narrowed it down is to break the method into smaller chunks. Since you can still see the method names in the stack trace, making more granular methods will help you to track down where the exception is being thrown.