I have a question about the best way of using HandleErrorAttribute in my MVC 5 application.
As we know, we can add this attribute to global filters like that:
filters.Add(new HandleErrorAttribute{View = "Error"});
This involves the app to show the 'Error' view every time when an unhandled exception is thrown in any level of app.
But, if I have some logic in another global authorize or action filter, that produces some exception, then when the exception is thrown for first time, the app tries to redirect to the Error View, again other filters begin executing and produce the same exception again, so asp.net to avoid looping terminates the app.
So what is the best way to use this HandleErrorAttribute to avoid such behavior?
Thanks!
Edit:
After some debugging I found that this is not the usual behavior of HandleErrorAttribute, so looping happens for me only when I use custom Routes f.e.
{key}/{controller}/{action}
and when some error occurs in the filter logic, then the app tries to redirect to the Error View, but again another filter logic begins to exectue and I even see an "Error" value in the {key} route parameter, so it is unwanted behavior.
When I use the default route {controller}/{action}
this doesn't happen and I get exactly to the Error View without executing any global filter logic a second time.
You should wrap your action filter logic inside a try catch, then inside the catch block, redirect to the Error view and pass the Exception.
Your only other alternative is to ditch HandleError completely and use the Application_Error event inside Global.asax to manage your error handling. That way you can redirect to your Error action inside there regardless of where the error occured.
Matt is right about global.asax... this is the example I followed
http://www.digitallycreated.net/Blog/57/getting-the-correct-http-status-codes-out-of-asp.net-custom-error-pages
Then in each view I added: Response.StatusCode = 500; or which ever other code I wanted to show back to the client.
Related
Ok, I have a weird problem and can't find anything about it online. I'm trying to get custom application-level error handling working in ASP.NET. I have customErrors turned off in the web.config with the hopes of handling everything in application_error. Bear with me...
My code in global.asax is very simple:
void Application_Error(Object sender, EventArgs e) {
HttpContext.Current.Trace.Write("ERROR MESSAGE");
Response.TrySkipIisCustomErrors = true;
var error = Server.GetLastError();
HttpContext.Current.Response.Write("ERROR MESSAGE");
HttpContext.Current.ClearError();
}
I created a simple aspx page and threw an error in Page_Init or Page_Load, and everything worked as expected, i.e.: I see "ERROR MESSAGE" on a blank page when an error occurs.
Now I dynamically add some user controls to that aspx page and everything renders as expected. If I then throw an error from INSIDE one of the controls, I only get a blank white page. "ERROR MESSAGE" does not appear.
Now I know that application_error is still firing because when I remove the call to ClearError(), I get a Yellow Screen Of Death. Also, I can execute a Server.Transfer in there and that works fine. But nothing will come out for Response.Write.
This goes further: I can set Response.StatusCode, but a Response.Redirect will error out (and thus throw me into an infinite loop). Trying to write to the Event Log also errors out, but instead of throwing a new error, it throws the original, i.e.: "Input string was not in a correct format." when I try to convert a string to a number. As mentioned, Response.Write doesn't do anything, though it does not throw an error.
So looking at my trace log, in the second case (exception inside dynamically added user control) I see a full control tree and the error occurs right after Begin Render. In the first case, the tree is empty and the error is thrown either after Init or Load. Both times, trace.axd reports Unhandled Execution Error.
When I move the throw inside the control to the control's constructor or OnInit, things work as expected. When I move it to OnLoad or Render, it gets goofy.
So I'm wondering if at some point the Response object loses certain functionality. I've tried all sorts of permutations, from syntax (using HttpContext.Current.Response vs Context.Response vs pulling the Response object from the "sender" parameter), to moving the ClearError() or Response.Clear(), etc methods around, etc. I've tested the Response object for "null-ness" as well, and it never reports a null. I can set some response properties (http status code) but not others.
I'm using IIS7.5 integrated mode (.NET v4), but experienced similar problems when I tried Classic mode.
So I'm trying to solve this mystery, obviously, but my goal is to ultimately handle all errors, no matter what point in the asp.net lifecycle they occur, and to be able to write out some information from the handler (ie application_error).
Handled unhandled exceptions using this approach. Custom error is off in web.config.
All 3 options work.
void Application_Error(object sender, EventArgs e)
{
// Code that runs when an unhandled error occurs
Response.TrySkipIisCustomErrors = true;
this.Server.ClearError();
this.Server.GetLastError();
//DO SOMETHING WITH GetLastError() may be redirect to different pages based on type of error
//Option 1:
Response.Write("Error");
//Option 2:
Response.Redirect("~/Error.aspx");
//Option 3:
this.Server.Transfer("~/Error.aspx");
}
When an exception is thrown by your own code that's called from an action in a controller how should that be handled? I see a lot of examples of best practices where there are no try-catch statements at all. For example, accessing data from a repository:
public ViewResult Index()
{
IList<CustomModel> customModels = _customModelRepository.GetAll();
return View(customModels);
}
Clearly this code could throw an exception if the call is to a database that it can't access and we are using an ORM like Entity Framework for example.
However all that I can see will happen is that the exception will bubble up and show a nasty error message to the user.
I'm aware of the HandleError attribute but I understand it's mostly used to redirect you to an error page if an exception that's unhandled occurs.
Of course, this code could be wrapped in a try-catch but doesn't separate nicely, especially if you have more logic:
public ViewResult Index()
{
if (ValidationCheck())
{
IList<CustomModel> customModels = new List<CustomModel>();
try
{
customModels = _customModelRepository.GetAll();
}
catch (SqlException ex)
{
// Handle exception
}
if (CustomModelsAreValid(customModels))
// Do something
else
// Do something else
}
return View();
}
Previously I have extracted out all code that could throw exceptions like database calls into a DataProvider class which handles errors and returns messages back for showing messages to the user.
I was wondering what the best way of handling this is? I don't always want to return to an error page because some exceptions shouldn't do that. Instead, an error message to the user should be displayed with a normal view. Was my previous method correct or is there a better solution?
I do three things to display more user-friendly messages:
Take advantage of the global exception handler. In the case of MVC: Application_Error in Global.asax. Learn how to use it here: http://msdn.microsoft.com/en-us/library/24395wz3(v=vs.100).aspx
I subclass Exception into a UserFriendlyException. I do my very best in all of my underlying service classes to throw this UserFriendlyException instead of a plain old Exception. I always try to put user-meaningful messages in these custom exceptions. The main purpose of which is to be able to do a type check on the exception in the Application_Error method. For the UserFriendlyExceptions, I just use the user-friendly message that I've set deep down in my services, like "Hey! 91 degrees is not a valid latitude value!". If it's a regular exception, then it's some case I haven't handled, so I display a more generic error message, like "Oops, something went wrong! We'll do our best to get that fixed!".
I also create an ErrorController that is responsible for rendering user-friendly views or JSON. This is the controller whose methods will be called from the Application_Error method.
EDIT:
I thought I'd give a mention to ASP.NET Web API since it's closely related. Because the consumer of Web API endpoints won't necessarily be a browser, I like to deal with errors a little differently. I still use the "FriendlyException" (#2 above), but instead of redirecting to an ErrorController, I just let all my endpoints return some kind of base type that contains an Error property. So, if an exception bubbles all the way up to the Web API controllers, I make sure to stick that error in the Error property of API response. This error message will either be the friendly message that has bubbled up from the classes the API controller relies on, or it will be a generic message if the exception type is not a FriendlyException. That way, the consuming client can simply check whether or not the Error property of the API response is empty. Display a message if the error is present, proceed as usual if not. The nice thing is that, because of the friendly message concept, the message may be much more meaningful to the user than a generic "Error!" message. I use this strategy when writing mobile apps with Xamarin, where I can share my C# types between my web services and my iOS/Android app.
With Asp.Net MVC you can also override the OnException method for you controller.
protected override void OnException(ExceptionContext filterContext)
{
if (filterContext.ExceptionHandled)
{
return;
}
filterContext.Result = new ViewResult
{
ViewName = ...
};
filterContext.ExceptionHandled = true;
}
This allow you to redirect to a custom error page with a message that refer to the exception if you want to.
I used an OnException override because I have several projects referenes to one that have a Controller that handle errors:
Security/HandleErrorsController.cs
protected override void OnException(ExceptionContext filterContext)
{
MyLogger.Error(filterContext.Exception); //method for log in EventViewer
if (filterContext.ExceptionHandled)
return;
filterContext.HttpContext.Response.StatusCode = (int)System.Net.HttpStatusCode.InternalServerError;
filterContext.Result = new JsonResult
{
Data = new
{
Success = false,
Error = "Please report to admin.",
ErrorText = filterContext.Exception.Message,
Stack = filterContext.Exception.StackTrace
},
JsonRequestBehavior = JsonRequestBehavior.AllowGet
};
filterContext.ExceptionHandled = true;
}
All questions like this are not very constructive, because the answer is always "it depends", because there are so many ways of dealing with error handling.
Many people like to use the HandleError method, because any exception is basically non-recoverable. I mean, what are you going to do if you can't return the objects? You're going to show them an error anyways, right?
The question becomes, how you want to show them the error. If showing them an error page is acceptable, than HandleError works fine, and provides an easy place to log the error. If you're using Ajax or want something fancier, then you need to develop a way to do that.
You talk about a DataProvider class. That's basically what your Repository is. Why not build that into your repository?
I am trying to handle all exceptions at my c# MVC application.
All controllers inherit from BaseController, so I thought I could override the OnException (protected override void OnException(ExceptionContext filterContext)).
But I don´t want to redirect to an error page, what I would like to do is to go back to the page that originated the request keeping its state. So if I had a form with an input filled by user, after handling the exception I want to show back that form with its input with the information filled by user.
Note: not all views are strongly typed.
example:
USER: myuser <-- text entered in input tag
After handling exception I want to go back to previous view showing exception message.
USER: myuser <-- text entered in input tag
My exception message
Validation should not be treated as unhandled exceptions! Please read about Model Validation in ASP.NET MVC in order to handle this scenario.
Unhandled exception is, as its name suggests, something that occurs only in exceptional cases. An exceptional case is something that when it occurs your application cannot process the request. So it doesn't make sense to redirect to a known state because there's no state when an unhandled exception occurs. The best you could do in this case is log the exception for further analysis and redirect the user to a 500 error page informing him that something went wrong.
Conclusion:
Use Model Validation to handle validation logic
Use OnException for unhandled exceptions.
I have an intermediary class extending System.Web.UI.Page for all of my pages that require authentication. The class mostly does custom authentication handling.
When a user with insufficient access attempts to visit a page, I try to redirect the user back to the login page while preventing any further page events from being executed (ie. Page_load). The first solution that came to mind was the default implementation of Response.Redirect. Of course the downside to this is the possibility of ThreadAbortExceptions being thrown.
So my question is this: When (if at all) during the page life cycle is it actually safe to execute Response.Redirect() without ThreadAbortException ever being thrown?
public class CustomPage : System.Web.UI.Page
{
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
if (!IsValid())
Response.Redirect("login.aspx", true);
}
}
It's never "safe" if you're passing true as the second parameter - it will always throw the exception. Internally, Response.Redirect() calls Response.End(), which directly aborts the current thread.
The only "safe" way to truncate an HttpRequest without having an exception thrown is by using HttpApplication.CompleteRequest(), but this will result in further code execution in the current request.
Curious, why are you doing this yourself? If anything, you should be using one of the authentication providers (ultimately, FormsAuthentication can be customized to handle almost any scenario you can think of).
Then, you can use the authorization element in your web.config file to indicate what pages/directories are not able to be accessed by anonymous users. ASP.NET will take care of the rest, redirecting the user to the login page you specify, as well as redirecting back when the user has logged in.
If you don't want a ThreadAbort exception you should pass False to the endResponse parameter. Of course this means you have to process the rest of the page, which is hard to get right.
Unless you are doing something really stupid like holding a lock, it is perfectly safe to throw a ThreadAbort exception in an ASP.NET page.
Another option is to use a Server.Transfer. This has better performance than a redirect, but it too uses ThreadAbort exceptions.
The questions says everything, take this example code:
<ul id="css-id">
<li>
<something:CustomControl ID="SomeThingElse" runat="server" />
<something:OtherCustomControl runat="server" />
</li>
</ul>
Now if an error gets thrown somewhere inside these controlls (that are located in a master page) they will take down the entire site, how would one catch these exceptions?
You can catch all exception not handled elswhere in the Global.asax page / class.
Look at:
protected void Application_Error(Object sender, EventArgs e)
method.
Unfortunately an unhandled exception will always error your site.
YOu can prevent this a few ways though.
Use the section in your web.config to show a user friendly message
In your Global.asax - or a Custom Handler - catch your unhandled exception and react accordingly - like this
best solution
Make sure you controls don't throw unhandled exceptions!
Add a global.asax en implement the Application_Error handler. Use the Server.GetLastError() function to get a handle on the exception thrown.
Using the global.asax Application_Error method, as described in How to create custom error reporting pages in ASP.NET by using Visual C# .NET.
An alternative approach would be to use a HTTP module; this gives you some more flexibility (you can handle errors from multiple applications, for example).
Do you want to catch the exception and handle it?
Or do you want to prevent the Yellow Screen Of Death? If you are trying to prevent the Yellow Screen Of Death, look at handling the Error event on the HttpApplication (in other words, in your Global.asax).
See the following MSDN page for more details:
http://msdn.microsoft.com/en-us/library/system.web.httpapplication.error.aspx
Specifically this paragraph:
The exception that raises the Error event can be accessed by a call to the GetLastError method. If your application generates custom error output, suppress the default error message that is generated by ASP.NET by a call to the ClearError method.