Today I ran into an issue that I hadn’t seen in a long time. I was asked to diagnose two errors. “Cannot Redirect after HTTP headers have been sent”, and some random “Object Reference not Set” errors.
After analyzing some of the logs, I found that they were always found after logging out. Digging further, I found this statement: Response.Redirect(url, false);
For those who might not know, the ‘False’ parameter causes a ThreadAbortException. Why? To make sure your requests ends immediately after that.
At first, I was tempted to ‘just’ change the parameter to ‘true’ and be done with it, but I wanted to know why one of my colleagues made this change. And interestingly enough.. it showed up in the history: “added ‘false’ parameter to prevent ThreadAbortException in the logs”. So, one of my colleagues probably found his logs were full of ThreadAbortExceptions. So he avoided the exceptions and now the logs were full of other, more cryptic errors.
So I figured out the best solution would be to make sure this ThreadAbortException was not being logged. It turns out that this exception already doesn’t reach the Global.asax Application_OnError method. So that wasn’t the source of the logging. it turned out that we had some exception handling logic built ourselves. So, adding a check to see if this was a redirect solved the issue. A little extension method Exception.IsCausedByRedirect() made the code a bit more readable: