I understand that if you put a Response.Redirect inside a try-catch that you're going to get this error unless you specify the 2nd param of the redirect as false.
But even looking at this article (PRB: ThreadAbortException Occurs If You Use Response.End, Response.Redirect, or Server.Transfer) I still don't understand why I have to set this to false for this particular line of code...we've always had true for that param until I wrapped that in a try-catch:
Response.Redirect(SecureUrl("Confirmation", SessionID), true);
We want to close it because it's the end of the line..the confirmation page. But when this is wrapped in the try-catch I get that error. I just want to understand better why false. I read the article and it doesn't jump out at me.
If you pass true as the second parameter, it will throw a ThreadAbortException to stop processing the request.
Code inside of ASP.Net will catch the ThreadAbortException, call Thread.ResetAbort, and send the (HTTP 301) response.
If you have a catch block, you will also see the ThreadAbortException, just as you'd see any other exception.
The best thing for you to do is to add an empty catch block for ThreadAbortException before your catch block, like this:
} catch(ThreadAbortException) { throw; }
Related
Executing the line:
Response.Redirect("Whateva.aspx", true);
Results in:
A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll
An exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll but was not handled in user code
The exception is because of the "true" part, telling it to end the current request immediately.
Is this how it should be?
If we consider:
Exceptions are generally considered heavy, and many times the reason for ending the request early is to avoid processing the rest of the page.
Exceptions show up in performance monitoring, so monitoring the solution will show a false number of exceptions.
Is there an alternative way to achieve the same?
You're right regarding the fact that the developer should avoid raising of (and catching) exceptions since the execution runtime consumes time and memory in order to gather the information about the particular exception. Instead he (or she) should simply not let them occur (when it's possible).
Regarding the Response.Redirect: this behavior is "by-design" but you might want to use a well-known workaround. Please read this KB article.
-- Pavel
One approach I generally take in this scenario is to not end the response during the response, but to follow it immediately with a return (or other flow control). Something like this:
Response.Redirect("Whateva.aspx", false);
return;
This depends on where the redirect is taking place in your logic flow, of course. However you want to handle it is fine. But the idea is that, when you want to end the response on the redirect anyway, then exiting the method in question via a return isn't out of the question.
One approach I've seen people take in this matter quite often, and it should go without saying that this is to be avoided but for completeness I'm going to say it anyway (you never know who may stumble upon this question later via Google, etc.), is to catch and swallow the exception:
try
{
Response.Redirect("Whateva.aspx", true);
}
catch (Exception ex)
{
// do nothing
}
This, of course, should not be done, for a number of reasons. As I inferred from your description of exceptions, you undoubtedly already know that this would be bad practice. But, as I said, it's worth noting this fact in the answer.
To work around this problem, use one of the following methods:
For Response.End, call the HttpContext.Current.ApplicationInstance.CompleteRequest method instead of Response.End to bypass the code execution to the Application_EndRequest event.
For Response.Redirect, use an overload, Response.Redirect(String url, bool endResponse) that passes false for the endResponse parameter to suppress the internal call to Response.End.
For example:
Response.Redirect ("nextpage.aspx", false);
If you use this workaround, the code that follows Response.Redirect is executed.
For Server.Transfer, use the Server.Execute method instead.
from:
http://support.microsoft.com/kb/312629/en-us
Same link posted by Volpav.
Regards.
A word to be said. This is the best .NET community ever. Keep it up !
I had a problem lately that I managed to have for it 2 solutions and I am wondering which one should I choose.
Here the issue :
When a user requests my site ( www..com), I am gonna redirect him to (www..com/en) because it is a multilingual site.
I am using .NET routing to to that.
In the Page_Load of the default.aspx page I check if the language in the Routing Collection is available, I don't redirect. If it is not available I redirect to (www.___.com/en). Here is the code :
if (Page.RouteData.Values.Count == 0)
{
if (SessionManager.IsUserAuthenticated)
{
//Redirect To User HomePage for his Main Language
Page.Response.Redirect(UserManager.GetUserMainPageWhenLoggedIn(SessionManager.LoggedUser.LanguageID,true));
}
else
{
Page.Response.Redirect(String.Format("~/{0}", Cultures.en.ToString()), true);
Helpers.SetCulture(Cultures.en.ToString());
}
}
I am using Response.Redirect to do that. Now if I set to End The Response the method parameter, it will throw an exception so I can handle it throught
try
{
this.InitializeLayout();
}
catch (ThreadAbortException ex)
{
}
catch (Exception ex)
{
ExceptionManager.LogException(ex);
}
If I don't end the Response, the page will execute the whole lifecyle, redirect and then do it again which results a double execution of the page.
My main objective is not to execute the page 2 times to minimize processing ( if the site gets hammered by a big traffic). If I end the Response, a ThreadAbortExeption will be thrown and I think this is not good for the site.( I can catch it and not log it).
What do u think guys?
You could avoid throwing the exception by, as you said, passing false to the endResponse parameter. If you want to then avoid executing the page, you could also call HttpContext.Current.ApplicationInstance.CompleteRequest(); which should skip the rest of the code on your page.
Note, however, that postback and render methods will still execute. If you want to avoid that, you must explicitly include code to ignore them. A great example of how to do this by overriding the RaisePostBackEvent and Render methods is here: --> http://www.c6software.com/articles/ThreadAbortException.aspx
You can use the Application_BeginRequest event handler in global.asax file or a HttpHandler to do your redirections. In both cases you will avoid 2 calls being made.
I would also suggest that you use server.Transfer instead of response.redirect.
I am just starting with ASP.Net. I copied a ex-co-worker's code (from .Net 1.1 era) and it has a Response.End(); in case of an error. There is also a:
catch (Exception ex)
{
Response.Write(ex.Message);
Response.End();
}
at the end of Page_Load(object sender, System.EventArgs e) which always appends "Thread was aborted." or something like that at the end. I suspect that this worked differently before, or the error conditions were not tested very well.
Anyhow, I was able to stop using Response.End(); in case when I do not like the GET parameters, and use return; instead. It seemed to do the right think in a simple case.
Is this Ok in general?
There are some problems with the code I copied, but I do not want to do a rewrite; I just want to get it running first and find wrinkles later. The Response.End(); caused a mental block for me, however, so I want to figure it out.
I want to keep the catch all clause just in case, at least for now. I could also end the method with:
catch (System.Threading.ThreadAbortException)
{
Response.End();
}
catch (Exception ex)
{
Response.Write(ex.Message);
Response.End();
}
but that just seems extremely stupid, once you think about all of the exceptions being generated.
Please give me a few words of wisdom. Feel free to ask if something is not clear. Thanks!
P.S. Ex-coworker was not fired and is a good coder - one more reason to reuse his example.
catch (System.Threading.ThreadAbortException)
{
Response.End();
}
catch (Exception ex)
{
Response.Write(ex.Message);
Response.End();
}
This actually won't even work. ThreadAbortException is a special case exception, and when your catch block is done, it is automatically re-thrown.
Just using return is definitely the best case, if the method you are in is the last thing that will be run in terms of your code. If it's not, and you want to end the request gracefully, you can call HttpApplication.CompleteRequest(), which will skip processing the rest of the lifecycle and jump directly to the EndRequest event processing.
According to the MSDN, all this call does is stop processing and return the current results. Therefore, calling Response.End() at the END of your processing should have no effect.
In practice, I've only used this to abort current processing mid way through.
You shouldn't be catching all your exceptions at this level. Use the Application_Error event in the global.asax to handle unexpected errors and provide a custom error page to show to your clients (see the customError section in the web.config).
In general, you should only catch exceptions you should handle, and you should not output error trace to your users. The response.end he is using is only required due to this odd error handling technique.
Look at it this way.. If your page has any other page methods that run after Page_Load in the page lifecycle (Page_Render, Page_PreRender), or if there is any other code directly after the try-catch - then you should leave the Response.End() in place.
If there's nothing like it - then you can remove them if you want, nothing should happen differently. But taking into consideration that this is an old internal (even legacy maybe? copied from .NET 1.1) app, not written by yourself, you can probably leave them in place.. They will definitely not hurt, and might save you from hard-to-catch strange problems, which are usually found in legacy apps :D
Could anyone tell me why a problem in the noun model would not be caught by this try catch?
I have tried this on two different controller methods now, and both times, even if the linq2sql doesn't allow the data to be saved, the code never jumps into the catch block.
I've watched the noun object in the middle of the trace, and the isvalid property is false, but the modelstate isvalid is true. Either way, the code never jumps into the catch block.
I'm pulling my hair out about this. I feel like it will be something really silly.
The code all works similar to nerd dinner.
NounRepository nounRepository = new NounRepository();
Noun noun = new Noun();
try
{
UpdateModel(noun);
nounRepository.Add(noun);
nounRepository.save();
}
catch (Exception ex)
{
ModelState.AddRuleViolations(noun.GetRuleViolations());
return View(noun);
}
return View(noun);
Update
I have just added this code, and now the rules are coming back to the front end fine, so it just seems that the try catch isn't catching!
UpdateModel(noun);
if (!noun.IsValid)
{
var errors = noun.GetRuleViolations();
ModelState.AddRuleViolations(noun.GetRuleViolations());
return View(noun);
}
nounRepository.Add(noun);
nounRepository.save();
I'd rather not have to add code in this manner though, as it seems like an unnecessary duplication.
You faced logical change in mvc - validation here do not throw exceptions. Indeed, you need to check it using if statement.
I doubt that exception is happening - you need to catch linq2sql exception anyway, code is correct. Also there is high a chance that inside 'save' or 'add' you have another catch - this is quite common mistake
Programming Rule #1: catch ain't broken (AKA: SELECT ain't broken).
If you're really in doubt, open up the Debug menu, choose "Exceptions", then tick the box for "Common Language Runtime Exceptions" under "Thrown." This will cause the debugger to break on all first-chance exceptions. If the debugger doesn't break during your update, then the exception is never getting thrown in the first place.
Don't forget to untick when you're done, as the behaviour gets pretty annoying under normal usage.
P.S. Never catch System.Exception. Catch the specific type(s) of exception(s) that you know might actually be thrown.
Are you doing something in another thread? That is often a cause exceptions not being caught.
Does Response.Redirect() cause the currently running method to abort? Or does code after Response.Redirect() execute also?
(That is, is it necessary to return/Exit Sub after a Response.Redirect?)
Response.Redirect has an overload accepting a boolean argument that indicates if the call to Response.Redirect should end the response. Calling the overload without this argument is the same as specifying true to indicate that the response should end.
Ending the reponse means that Response.End is called after the response has been modified to make the redirect happen, and Response.End throws an ThreadAbortException to terminate the current module.
Any code after a call to Response.Redirect is never called (unless you supply false for the extra argument). Actually, code in finally and certain catch handlers will execute, but you cannot swallow a ThreadAbortException.
This may not be a complete answer, but from what I've seen...
Response.Redirect does, actually cause the code to stop executing by throwing a System.Threading.ThreadAbortException.
You can see this for yourself by setting up global error handling in the Global.Asax and testing a Response.Redirect.
EDIT
and here is a link to the documentation that supports my answer:
Redirect calls End which raises a
ThreadAbortException exception upon
completion.
HttpResponse.Redirect Method (String, Boolean) (System.Web)
There is another parameter to Response.Redirect called endResponse. Setting it false is a good idea when you're redirecting in a try catch block because the context still needs control to be correct. So your catch block will pick up the exception.
The caveat to that is that when the page is not Cancelable then it won't try to get control. The most common case of this is Global.asax. So you don't need to worry about this exception in that context. If you don't believe me try reflecting the code for this method and take a look.
So to answer your question it isn't necessary to do much after a Response.Redirect when you set endResponse to true which it is by default (i.e. called with the method that doesn't take a bool).
My understanding is that upon issuing a Response.Redirect(), code following it will not execute. If you think about it, it would make sense not to execute it. You're basically telling your code that you want to go somewhere else.
Example: Think of it as ordering a value meal at McDonalds. After you order it and they start filling your drink, you change your mind and say "you know what, forget my order. I'm going to Redirect myself to Wendy's." At that point, they're going to stop making your fries and burger because, well... you've decided to go somewhere else -- i.e. redirecting the response.