I\'m redirecting to an Error page with a prettified error message in my Application_Error
, in Global.asax.
At the moment it says:
Respon
Here it is best to use true
, because you want all the other threads to abort; there has been an error and the application cannot continue.
Response.Redirect(URL,false): The client is redirected to a new page and the current page on the server will keep processing ahead.
Response.Redirect(URL,true): The client is redirected to a new page, but the processing of the current page is aborted.
You can also see this video which demonstrates the differences Response.Redirect ( False vs True) ASP.NET Interview questions with answers.
You never need to use true
, as there is an overload without the boolean parameter.
Response.Redirect("Error.aspx", false);
or
Response.Redirect("Error.aspx");
The boolean parameter was added so that you could set the redirect without stopping the execution. If you can exit out of the page code yourself without that causing any extra cost, like for example data binding occuring, that is preferable.
If you set it to true, the application ends the response and sends it back to the user, and if you set it to false the code after the redirect will continue to be executed, and the user will be redirected to the new page after the full page-load life cycle ends.
You use false
when you don't want to abort the thread. What that means is that false
will cause the code to continue to execute. So lines of code which appear after the Response.Redirect
will be executed. A true
will just kill the thread so nothing further will execute, which in turn throws a ThreadAbortException
.
So it's really a judgment call based on how the rest of the code in that situation looks. Generally you want to put calls to Response.Redirect
at the end of an execution path so that nothing further needs to be executed. But many times that's not the case. It's just a matter of how you control the logic flow in the code.
For example, if the next line after Response.Redirect
is a return
and the execution path simply ends, then you're probably fine. But if there's all kinds of logic and executing it in this case would leave the system in an unknown state, then you may want to abort the thread.
Personally I consider aborting the thread to be indicative of poor logic control. It's similar to a well known code smell where exceptions are used to control logic flow, which is universally frowned upon. If you can control the logic flow without the need for aborting a thread and throwing an exception, that would probably be preferred.