10

I have a Response.Redirect in my Employee page. It redirects to Salary page. 

Response.Redirect ("Salary.aspx");

It was working fine until I added exception handling as below.

try
{
   Response.Redirect ("Salary.aspx");
}
catch(Exception ex)
{
//MyLog();
    throw new Exception();
}

//Remaining code in event handler

This caused a new exception saying "Thread was being aborted”. I came to know that this can be avoided by setting endResponse as false for the redirect. 

Response.Redirect(url, false);
Context.ApplicationInstance.CompleteRequest();

Explanation of new exception: It always throws the exception but handled by the framework. Since I added a try..catch it was caught there (and I am throwing a new exception)

Note: CompleteRequest does bypass further HTTP filters and modules, but it doesn't bypass further events in the current page lifecycle

Note: Response.Redirect throw this exception to end processing of the current page. ASP .Net itself handles this exception and calls ResetAbort to continue processing.

QUESTION

  1. Whether “setting endResponse as false” can increase performance since the exception is not thrown ?
  2. Whether “setting endResponse as false” can decrease performance since the page lifecycle events are not terminated?

PITFALL

  1. If you set endResponse as false, remaining code in the eventhandler will be executed. So we need to make a if check for the remaining code (Check: if redirection criteria was not met).

Reference

  1. Why Response.Redirect causes System.Threading.ThreadAbortException?
  2. ASP.NET exception "Thread was being aborted" causes method to exit
Community
  • 1
  • 1
LCJ
  • 22,196
  • 67
  • 260
  • 418
  • `Performance` can be measure from different aspects !!! what you exactly expecting? – huMpty duMpty Dec 05 '12 at 16:17
  • @huMptyduMpty Performance from following perspectives 1) Page Response Time 2) Memory usage – LCJ Dec 05 '12 at 16:19
  • 1
    Also, since you trying to improve your website performance, this [article](http://msdn.microsoft.com/en-us/magazine/cc163854.aspx) might give some information as well – huMpty duMpty Dec 05 '12 at 16:32
  • 2
    I think that if you're concerned about `Response.Redirect` throwing an exception is causing performance problems, then you might optimizing prematurely. – Matthew Dec 05 '12 at 16:35
  • 2
    Your problem is that you're doing exception handling badly. Just get rid of such try/catch blocks and instead use [ASP.NET Health Monitoring](http://msdn.microsoft.com/en-us/library/bb398933%28v=VS.100%29.aspx). – John Saunders Dec 06 '12 at 05:25

1 Answers1

12

Ending the response (Response.Redirect(url) or Response.Redirect(url, true)) will not have better performance than Response.Redirect(url, false). With false, since you have control over the code execution, you can simply not execute any more code in the case when you are going to redirect the user.

This is specified in the MSDN entry for Response.Redirect():

If you specify true for the endResponse parameter, this method calls the End method for the original request, which throws a ThreadAbortException exception when it completes. This exception has a detrimental effect on Web application performance, which is why passing false for the endResponse parameter is recommended.

You DO need to be concerned about the page lifecycle events, as you noted. You shouldn't continue executing the page events if you are going to Redirect the user (not only for performance). I recently wrote a brief example showing what can happen with poor coding/planning if you don't.

The bottom line of that post is that Response.Redirect() returns a 302 to the browser. There is a potential for problems when you use Response.Redirect(url, false) since the page execution continues, and the user can choose to ignore the 302 and instead see the page that would've been rendered... so you need to take steps to ensure they don't see anything you don't want them to see. The NoRedirect add-on for Firefox is helpful when testing this.

For best performance: use "false" as the endResponse parameter, ensure you aren't running any further code, and ensure the page isn't going to render any information you don't want a user to see if they ignore the 302.

MikeSmithDev
  • 15,731
  • 4
  • 58
  • 89