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
PITFALL
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
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With