Geek Answers Handbook

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

I was wondering if I need to save the return after my call to Response.RedirectPermanent in my code? It does not look like this, but I wanted to confirm with others.

 Response.RedirectPermanent(vpd.VirtualPath); return;

Is there a reason for this or to increase productivity or productivity?

+4
source share
2 answers

Overhaul response:

Hold the phone! The details in my previous answer were, following further research, completely wrong. In fact, the following is stated in the MSDN documentation:

When you use this method in a page handler to complete a request for one page and run 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 when it finishes. This exception has a detrimental effect on web application performance, so it is recommended that you pass false for the endResponse parameter.

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

Thus, in fact, the rest of the page is not executed (theoretically - see "Updating" below for an example when this crashes); however, there is still an acute problem with what you are doing, since the endResponse mechanism endResponse implemented by throwing a ThreadAbortException , which is a relatively expensive way to stop processing the current thread.

Instead, you should say that the thread continues, but returns immediately - also make sure the other methods in the call stack do what they need:

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

Even better, wrap the call in a conditional expression to ensure that the unwanted code will not be called, and then use the CompleteRequest method (which does not complete the current executable 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 topic, and even the documentation itself seems to have an unhealthy aversion to the HttpResponse.End method , which is called if you allow Response.Redirect to disable the response for you.

Update: Also, given that the thread terminates with an exception, think about what happens if you try to redirect inside try / catch:

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

The exception thrown by Response.End falls into your catch block. The rest of your code, however, is executing, and you accidentally deleted all _currentUser data (unless you do something to prevent this from _currentUser in your catch , such as throwing an exception on the caller).

+4
source

I 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

The code after RedirectPermanent not executed, so Iguess using return or not will have the same effect.

+2
source

More articles:


All Articles