I was doing some load testing the other year and noticed one of the counters was going off the charts - ASP.Net exceptions. I couldn't understand why my application, which was behaving fine in every other way, was throwing exceptions.
It turned out that I have been doing a Response.Redirect from the OnInit of a Page that was inheriting from a custom Page class which had a try/catch. The exception was a ThreadAbortException. I quickly added a catch clause to grab the ThreadAbortException and ignore it, but what could I have done to avoid throwing an exception at all?
One of the most common calls in the whole of ASP.Net is Response.Redirect - which sends an HTTP 302 response back to the browser and does one of the most common things that all multi-threaded system do - throws a ThreadAbortException to exit the current Thread.
It turns out that there is another way to do this, assuming you can handle the conditional logic to ensure the current Response doesn't get mashed up before you send it to the browser. It involves the little-known CompleteRequest() method, which essentially tells ASP.Net to skip any more events in the Pipeline, Handler or Module and just send the Response straight back to the client.
Here's my example of redirection method that doesn't throw an Exception.
As you can see - the only "customized" piece of logic is where we set the StatusCode of the Response to 302 (the 300 series of response codes are all different kinds of redirects, but 302 seems to do the trick for whatever you need). The rest of the method just sets properties of the Response object (like RedirectLocation).
The net effect? The same as Response.Redirect - except no exception. :)
Rock on - joel.