In ASP codebehind, is there any benefit to adding the return keyword after a redirect?

Question

I was wondering whether if it was necessary to keep a return statement after my Response.RedirectPermanent call in my codebehind? It doesn't seem like it, but I wanted to confirm with others.

Response.RedirectPermanent(vpd.VirtualPath);
return;

Is there any reason to do so either for a functional or performance gain?

Answer 1

Answer overhaul:

Hold the phone! The detail in my previous answer was, following further research, not at all true. In fact, the MSDN documentation specifies the following:

When you use this method in a page handler to terminate a request for one page and start a new request for another page, set endResponse to false and then call the CompleteRequest method. 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.

http://msdn.microsoft.com/en-GB/library/a8wa7sdt.aspx

So, in actual fact, the rest of the page is not executed (in theory - see 'Update' below for an example of when this falls over); however, there is still a very tangible issue with doing it the way you are, which is that the endResponse mechanism is implemented by throwing a ThreadAbortException, which is a relatively expensive way of terminating the processing of the current thread.

Instead, you should tell it to let the thread continue, but return immediately - also be sure that other methods in the call stack are doing what they should:

Response.RedirectPermanent(vpd.VirtualPath, false);
return;

Better yet, wrap the call in a conditional to ensure that undesirable code doesn't get called and then use the CompleteRequest method (which does not terminate the currently-executing code but will bypass all subsequent events):

if (_redirecting)
{
    Response.RedirectPermanent(vpd.VirtualPath, false);
    Context.ApplicationInstance.CompleteRequest();
}
else
{
    /* Code I don't want to execute if I do a redirect */
    DeleteUsersDataForever(_currentUser);
}

There's an in-depth article on this very topic here and even the documentation itself seems to have an unhealthy distaste for the HttpResponse.End method, which is what's called if you allow Response.Redirect to do the response termination for you.

Update: Additionally, given that the thread is terminated by raising an exception, consider what happens if you try and do your redirect inside a try/catch:

try
{
    // Redirect and terminate execution
    Response.Redirect(someUrl, true);
}
catch
{
    // Handle some errors.
}

DeleteUsersDataForever(_currentUser);

The exception that's raised by Response.End is caught in your catch block. The rest of your code is, therefore, still executed and you have accidentally deleted all of _currentUser's data (unless you do something to prevent this in your catch block, such as bubbling the exception to the caller).

Answer 2

I have tried the code below :

Page1.aspx

protected void Page_Load(object sender, EventArgs e)
{
   Response.RedirectPermanent("~/Page2.aspx");
   Session["afterRedirect"] = "after redirect";
}

Page2.aspx

protected void Page_Load(object sender, EventArgs e)
{       
   Response.Write(Session["afterRedirect"] ?? "nothing to show");
}

Result

nothing to show

Code after RedirectPermanent does not execute so Iguess using a return or not will have the same effect.