I have MVC3 application where it is extremely important that all errors that may happen in production will be properly logged.
Current approach uses IExceptionFilter.OnException. The functionality is applied on BaseContorller, from which all other controllers inherit, and looks (slightly simplified) as follows:
public class BaseController : Controller, IExceptionFilter
{
protected override void OnException(ExceptionContext exceptionContext)
{
Logger.Error(exceptionContext.Exception);
}
}
This approach works very well, for:
-
exceptions that originate in code within controller action methods
-
exceptions that originate in views returned by controllers methods,
including compilation errors - exceptions in filters applied to controller
However there are exceptions that will not be caught using this approach:
- exceptions thrown within controller constructor
- exceptions thrown in application routines such as: RegisterGlobalFilters, RegisterRoutes, Application_Start
- page not found (404)
Are there any other types of exceptions you can think of that can be missed with controller level exception handling?
I am asking because I will likely implement additional layer of logging using Application_Error or ELMAH, and I want to verify that none of those exceptions slips through unlogged.
Anything that doesn’t go through the MVC pipeline would not be caught by this implementation. HttpHandlers, WebAPI implementations, ServiceStack addition, etc.
An additional layer of Elmah doesn’t hurt, but I would probably just pick one or the other. If you fragment your error handling you could be doubling your work when debugging.
“Did my logger catch it or did Elmah catch it?”
Since Elmah is close to the ASP.NET metal, I would just stick with Elmah and keep your exceptions in one place.
As a side note, you might still want a logger to do tracing but that is a lot more explicitly expressed in your code than an unhandled exception.