Why Response.Redirect Causes System.Threading.Threadabortexception

Why Response.Redirect causes System.Threading.ThreadAbortException?

The correct pattern is to call the Redirect overload with endResponse=false and make a call to tell the IIS pipeline that it should advance directly to the EndRequest stage once you return control:

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

This blog post from Thomas Marquardt provides additional details, including how to handle the special case of redirecting inside an Application_Error handler.

Response.Redirect and thread was being aborted error?

I catch this exception and swallow it because ASP.NET is using exceptions for flow control rather than for an exceptional circumstance.

try
{
    // Do stuff.
}
catch(ThreadAbortException)
{
    // Do nothing. ASP.NET is redirecting.
    // Always comment this so other developers know why the exception 
    // is being swallowed.
}
catch(OtherExceptionTypes ex)
{
    // Log other types of exception.
}

Thread was being aborted. For response.redirect. how to redirect when session is Null in following code

Move the Response.Redirect portion of code to somewhere outside of the Try..Catch block.

The way Response.Redirect works in ASP.net is that is purposefully throws an exception to completely halt the further processing of the web page. This helps ensure that your redirect works properly, and that further processing actions do not cause conflicting behavior.

Here is another SO post with more information, and alternative solutions:
Why Response.Redirect causes System.Threading.ThreadAbortException?

Edit

I didn't notice the async on the Page_Load method at first. That would explain why you are still seeing the error. Please see these SO questions:

ASP.NET 4.5 async-await and Response.Redirect

Response.Redirect issue with Asp.net async

System.Threading.ThreadAbortException caused by Response.Redirect

Don't just catch the exception. Use the overload of Redirect which takes a boolean. Pass false to indicate that you don't want the thread aborted.

Getting Thread Abort Exception while using Response.Redirect()

Even though, i solved this problem , i would like to know is there any mistake in the way i am coding

No mistake, you've done well.

This error is expected. It's thrown because the server thread is in fact aborted when redirecting. From the MSDN documentation:

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.

and the documentation for the overload you're using:

Redirect calls End which throws a ThreadAbortException exception upon completion.

Response.redirect raises Thread was being aborted

By default, Response.Redirect() aborts the current thread. Naturally, this throws a ThreadAbortException. It can be prevented by passing a false to Response.Redirect(), which won't abort the current thread.

Be aware of what that means, however. If the thread is not aborted, the code following the Response.Redirect() will continue to execute. Control your logic flow accordingly. (This is often done with return statements and other flow control directives following a redirect.)

ThreadAbortException not catched properly in WebMethod

Why it is treating System.Threading.ThreadAbortException differently
from other exceptions?

For your first question, From ThreadAbortException on MSDN:

ThreadAbortException is a special exception that can be caught, but it
will automatically be raised again at the end of the catch block. When
this exception is raised, the runtime executes all the finally blocks
before ending the thread. Because the thread can do an unbounded
computation in the finally blocks or call Thread.ResetAbort to cancel
the abort, there is no guarantee that the thread will ever end. If you
want to wait until the aborted thread has ended, you can call the
Thread.Join method. Join is a blocking call that does not return until
the thread actually stops executing.

I think to prevent that, you need to call Thread.ResetAbort() in the catch block.

[WebMethod]
[ScriptMethod(UseHttpGet = true)]
public static string TestException()
{
    try
    {
        System.Web.HttpContext.Current.Response.Redirect("Test.aspx");
        return "No Exception";
    }
    catch(ThreadAbortException ex)
    {
        Thread.ResetAbort();
        return "Exception";
    }

}

And using Response.Redirect in a WEB METHOD isn't a good practice! When you are using WEB METHOD you should follow SOAP rules. And you need to know calling Response.Redirect will call Response.End.

HttpResponse.Redirect Method page at MSDN:

An absolute URL (for example, http://www.contoso.com/default.aspx) or
a relative URL (for example, default.aspx) can be specified for the
target location but some browsers may reject a relative URL. Redirect
calls End which raises a ThreadAbortException exception upon
completion.

ASP.Net WebForms - how to mitigate Thread Aborted exception when using async code + Response.Redirect

Well, since that code call is to run and go off and do its own thing?

Then of course that code can't update the page, since the page will render, and be send off and down to the client side.

Your code behind as a general rule can't wait.

So, start that process outside of the web form - after all, that async code has nothing really to do with the page, right? Since the page will have LONG been rendered and send down to the browser side while that code goes off and runs and does whatever it supposed to do, right? of course the code can't wait, and you can't hold up the page being sent down to the browser, since if you do that, then your code not async anymore, is it?????

so, do this:

{
Thread mypthread = new Thread(_userService.GetUser(););
mypthread.Start();
}

After all, that routine has nothing to do with the current page, and the current page can't wait, since if it waits, then the page will be held up until all that processing is done and THEN MAKE the trip down to the browser side.

So, you can't block or hold up the round trip.

Page post back - browser travels up to server.
Code behind runs, new page is rendered, maybe code behind changes things on that page.

Page travels down back to browser and is now just sitting there.

So, if you going to fire off some other routine that you don't want to wait for? Sure, just start it in a new thread OUT SIDE of that all important round trip. But you certainly can't fire off some async code, but THEN wait for it to complete, and THEN let the page continue being rendered. As noted, to do so would defeat the whole purpose of async code.

---

Related Topics