If you log exceptions, watch out for Response.Redirect() – level 200

A common practice with any web application is to log fatal exceptions. After all, if the user can’t complete the intended operation, wouldn’t you want to know about it? I log all fatal exceptions in my apps because if one of these happens, I want to know about it so I can fix the bug. Often, a production environment will uncover bugs in fringe use cases — bugs that would never turn up in the normal test cycle. The exception information can help you reproduce and fix the bug.

Recently I employed the use of Response.Redirect( ) for a situation where I wanted to stop doing the work on the current page and go to another that was dependent on the query string. I used Response.Redirect( ) for this, and my exception log started growing. After investigation, I found that a ThreadAbortException was being thrown with every Response.Redirect( ) call. By looking at the call stack, I discovered that Response.Redirect( ) actually calls Response.End( ) internally. Response.End( ) throws the ThreadAbortException to terminate work on the current thread after sending the redirect message.

David Neal 6:58 am on February 14, 2005

I recently discovered this same issue in a few situations in my own code. After identifying the try..catch blocks where the ThreadAbortException was being logged, I just added a catch for ThreadAbortException that did nothing.

This was also happening in my RSS feed, where when after rendering the XML I was calling Response.End(). Talk about your event log filling up…
Jeffrey Palermo 7:17 am on February 14, 2005

That’s interesting. Another way I like to identify exception is to test the type and do different things with them. In my high-level try/catch, I could do if(ex is ThreadAbortException) //do whatever;
else //do whatever.
Dustin DeFoe 7:33 am on February 14, 2005

You can also use:

Response.Redirect("mypage.aspx", False)

The second paramater is an optional EndResponse that is True by default. Setting this value to false will not raise an exception and thus allow you to continue through your code and then will redirect later after the rest of the code has been processed.
Jeffrey Palermo 7:45 am on February 14, 2005

Yes, and I would use that overload with "false" if I was already at the end of my page logic, and there was no performance penalty for allowing it to finish, but if my redirect is early in the page cycle, and I have some fairly expensive logic later on, I would want to prevent that logic from running for nothing and use Response.End( ).

Great tip!

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

If you log exceptions, watch out for Response.Redirect() – level 200

Related