I need More information on HandleError

Question

Hi

I am not sure what the difference between the different ways to HandleError.

In the asp.net mvc(default project) they put this on top of the class

[HandleError]

So I was reading some blog and the person says this

"....tells the framework that if an unhandled exception occurs in your controller that rather than showing the default Yellow Screen of Death it should instead serve up a view called Error."

http://blog.dantup.me.uk/2009/04/aspnet-mvc-handleerror-attribute-custom.html

So does that mean I should not be catching any errors(ie no try catches)?

I then was looking in a book and they have

[HandleError(ExceptionType=typeof(InsufficientMemoryException),View="About")]
public ActionResult HandleError()
{
    throw new 
InsufficientMemoryException();
    return View("Home");
}

So they just put it on top of this ActionResult and give it an exception type. My first question is what happens if you have more then one error that you are throwing? Also I thought you should handle all errors. I know this is just a little example but should you not catch the MemoryException somewhere or does this screw up "HandleError" if you do?

I also noticed while looking at it in VS that HandleError has 2 overload methods. One of them being the above and the other being HandError().

So why is in the asp.net MVC sample file just [HandleError] and not [HandleError()]? Is one used for action methods and one used for class ones? I am assuming HandleError at top of the class one is would be like HandleError(typeof(Exception))?

and Lastly there is something called IExceptionFilter. So you is use this if you want to log all exceptions or if you have some special exceptions that you want to do something differently with?

Like if I just wanted to log all exceptions no matter what would I just make one of these and thats it but if I wanted to do something special at a NullReferenceexception I would make another one?

I was watching this tutorial http://dimecasts.net/Casts/CastDetails/37 and I don't see this "ActionFilterAttribute" they are talking about. Is this from an old version or something?

Like apparently it has 4 methods that you can use and you have to override them. In my book it only talks about these:

1. IAuthorizationFilter
2. IActionFilter
3. IResultFilter
4. IExceptionFilter

and they are all interfaces so no overriding. Non of them though have 4 methods. Only one or 2.

Thanks

Oh one more thing. Should you always test for every single exception? Like one of my methods can encounter 7 different exceptions. Should I test for all 7 exceptions(ie throw them) then eventually catch them and handle them(I usually just print some message out).

If so does VS2008 have something that finds the exceptions that can happen. I find it hard to tell sometimes what can be throwing an exception then I have to hunt down which ones.

Answer 1

First biggest thing to note is that you should always trap errors that you know might occur. Next, you shouldn't try to trap every single error known to man...you could be in your code all day adding such things. The [HandleError] attribute is essentially a global error handler that says if any error happens in this controller send them to the configured page. This is nice in that out of the box you are handling all errors nicely! The next thing is handling a specific error in a certain way. You can say if XYZ error occurs go to this page instead of the globally handled error page. If multiple errors occur...the first one wins. Meaning if you plan to catch two types of errors...which ever one occurs first will control which page you are redirected too.

The next thing that you might consider for any asp.net site (webforms or mvc) is the ELMAH framework. It will log and capture every single error that your site causes. This will help you to address any errors that you are not aware of...so that you don't have to plan for them all up front. The nice thing about this framework is that you can have it send you an email when an error happens as well as log it to an xml file (among other configuration possibilities). Very handy!

Hope I addressed all your queries!

Answer 2

"Never" trap System.Exception. You could be hiding a problem. Better to "Fail Fast."

Only trap exceptions that:

• You know can occur and
• That you can gracefully recover from and
• That you can't pre-emptively check for

So to answer your last group of questions, I wouldn't trap those exceptions if you can check for the conditions in code. For instance, if FileNotFound is one of them, rather than trap FileNotFoundException, check for the file. If NullReference is one, check if the object is null instead of catching the Exception.

Andrew's suggestion to use ELMAH for logging unhandled exceptions, or any exception for that matter, is a great one, IMO.