I am learning ASP.NET and was looking at QueryStrings.
One of the examples I was looking at hooks a button up to a redirect call:
protected void btnSubmit_Click(object sender, EventArgs e)
{
try
{
//throws ThreadAbortException: "Thread was being aborted"
Response.Redirect("Form2.aspx");
}
catch (Exception Ex)
{
System.Diagnostics.Debug.WriteLine(Ex.Message);
}
}
Why does it throw a ThreadAbortException here? Is that normal? Should I do something about this? Exceptions are generally not a good thing, so I was alarmed when I saw this.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
This is by design. This KB article describes the behavior (also for the Request.End() and Server.Transfer() methods).
For Response.Redirect() there exists an overload:
Response.Redirect(String url, bool endResponse)
If you pass endResponse=false, then the exception is not thrown (but the runtime will continue processing the current request).
If endResponse=true (or if you use the overload without the bool argument), the exception is thrown and the current request will immediately be terminated.
Method 2
This is normal. Server.Transfer() also throws the same exception.
This is because internally, both methods call Response.End(), which aborts the current request processing immediately. Rick Strahl has a pretty good blog post that analyzes why there is pretty much nothing you can do to avoid these exceptions.
Method 3
Response.Redirect calls Response.End internally, so it throws the exception, use instead :
Response.Redirect(url, false);
Method 4
It’s normal in that it’s what’s meant to happen. Basically when the response has been set to a redirection, ASP.NET expects that you’re completely done with the request. It aborts the thread as a way of preventing any other processing from occurring (basically it calls Response.End for you, and that throws the exception).
It seems to me that it’s a bit of an abuse of exceptions, but that’s the way it works. You can use the overload which has a second parameter (and pass false) to prevent this from happening if you want to – but if so, make sure that nothing else then tries to write to the response!
Method 5
I believe you need to follow the instrucitons in this KB article. Response.Redirect calls Response.End(), unless you used the overload specifically made to avoid this behavior. Once the response has been ended, no further operations can happen hence the TA exc.
http://support.microsoft.com/kb/312629
Method 6
The behavior is by design to support old asp. Here is the link from MS describing what you are experiencing.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;312629
Method 7
Calling the overload of Redirect() that just takes a URL also results in a call to Response.End() – which throws a ThreadAbort exception to ensure that no other code after the redirect in your page/UC is run.
You shouldn’t catch this exception .. you should either ignore it in your code or use the overload of Redirect() which takes a boolean that indicates whether to continue processing the request after the redirect.
Method 8
Yeah. I code an exit sub after those but I know it’s not reached.
I suppose if you wanted to you could eat the exception and carry on more stuff afterwords but I wouldn’t recommend it.
Method 9
Already a bunch of reasonable answers here. One other point worth noting though. The Thread Abort Exception is one of those rare exceptions that you can catch and code against, but you can’t suppress. It gets automatically re-raised at the end of any try/catch/finally block regardless of what you do.
And if you decide to live with this exception, you should ensure that your health monitoring allows for this and doesn’t report it as an issue, so you don’t get stuck in front of a bunch of non-technical managers trying to explain why your website is throwing so many Thread Abort Exceptions. (I had a manager convinced that all these thread abortions were leaving a mess behind which of course was the complete opposite to the intention of the thread abort.)
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0