In ASP.NET web applications, the Response.Redirect(string url) method is often used to control the flow of an application (both user browsing and logic) by redirecting the client to a different URL. For example, on a page that requires an authentication user, it is quite standard to first check if the user is logged in and if they aren’t, call Response.Redirect(“login.aspx”). This is all great, except that many developers probably don’t know what’s actually going on under the covers.
Under the covers
Internally, Response.Redirect (and Server.Transfer for that matter) calls Response.End to end the page’s execution (rather abruptly) and then shifts the execution to the Application_EndRequest event in the application’s Global.asax. We rely on this behaviour to bail out of wherever we were when we decided to call Response.Redirect. What most people probably don’t realize is that Response.End raises a ThreadAbortException exception. Exceptions are expensive, and if you’re calling Response.Redirect often, you might find this particular behaviour detrimental to the performance of your site.
So, how do I avoid these exceptions?
Well, Response.Redirect actually has an overload that takes two parameters – Response.Redirect(string url, bool endResponse). If you use this overload instead and pass false to the endResponse parameter, the internal call to Response.End will be suppressed and as such, no ThreadAbortException exceptions will be raised.
Great! But wait, there’s more…
There is a side effect! Using this overload and passing false so that Response.End doesn’t get called means that any code after the call to Response.Redirect will now be executed where it wouldn’t have previously. This makes perfect sense – if Response.End isn’t called then the execution isn’t shifted to the Application_EndRequest event and if the execution isn’t shifted, then it will carry on executing wherever it currently is. That’s right – although you no longer get ThreadAbortException exceptions being thrown, Response.Redirect no longer controls the flow of your logic.
This is fine if you are calling Response.Redirect at the end of a method at the bottom of your call stack because there was probably no more code to be executed anyway. On the other hand, if you are calling this from inside a method that isn’t at the bottom of your call stack, you have to be careful with the remaining stack calls. Even if you call return straight after you call Response.Redirect, where are you ‘returning’ to? Another method that executes more code? Eeek!
None of this is news – it’s all explained in this Microsoft Support article. However, I really don’t feel that it emphasizes enough the negative effects that switching over to the Response.Redirect overload may have on your application. You simply can’t go through your application and replace every Response.Redirect with it’s overload without thinking carefully about what this might do to the logic of your application. The ‘flow’ may still look like it’s working as it should because the user will still be redirected to another page, but under the covers you might find that you’re now executing code that you weren’t before and that may have some pretty nasty unwanted effects.