MVC3 What Level Should I Catch Errors - asp.net-mvc-3

Question

I have a website which is utilzing MVC3. I have an n-tier architecture and I am curious at what level it is best to catch errors.
For isntance let's say I have a Students table I have a StudentRepository with a function such as:
StudentRepository.GetHightestGrade(studentId)
So should I have my Repositry function have a try/catch block - or should I put the try/catch directly into the ActionResult function. OR would I be better served adding in a business class and then my ActionResult function would do something such as
Business.GetHighestGrade(studentId) and that function simply has a try/catch and calls the Repository function?

Answer 1

You should really only wrap methods in try/catch if you are trying to prevent errors from bubbling up the stack. Generally it's best to put the try/catch at the top layers, to shield the users from the errors. Lower layers should generally throw exceptions during exceptional circumstances, you should only try to catch them in higher layers.
You will find your code is much more readable without a ton of try/catch blocks, I personally try to avoid them when I can, and let the MVC3 HandleError filter attribute take care of displaying error messages. However sometimes you may want to retry an operation if it throws an exception, which makes a good try/catch candidate.
Take a look at ELMAH -- using it should help you write code that avoids exceptions in the first place. But you should only explicitly try/catch if you are expecting an exception, and want to take some action in response to it.

Answer 2

it depends on what you wanna do in the catch, do you just wanna fail silently? do you wanna log the error? do you wanna return a view to notify the user that something went wrong?
if you just wanna notify the user, then catch it in the controller.
if you wanna log it, then catch it in your repo, and have your repo do the logging through some logging service, you could use some higher service that does the call catch the error and log it, but that might be an over kill.

Answer 3

you should write a global filter attribute for custom exceptions. Catch all exception over that filter and return to view. Something like that
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Text;
namespace Filters
{
public sealed class HandleException : FilterAttribute, IExceptionFilter
{
public void OnException(ExceptionContext filterContext)
{
if (filterContext == null)
throw new ArgumentException("filterContext");
else if (typeof(AjaxException).IsInstanceOfType(filterContext.Exception) && !filterContext.ExceptionHandled)
{
filterContext.ExceptionHandled = true;
filterContext.HttpContext.Response.Clear();
filterContext.HttpContext.Response.ContentEncoding = Encoding.UTF8;
filterContext.HttpContext.Response.HeaderEncoding = Encoding.UTF8;
filterContext.HttpContext.Response.TrySkipIisCustomErrors = true;
filterContext.HttpContext.Response.StatusCode = 400;
filterContext.Result = new ContentResult
{
Content = "Unexpected error",
ContentEncoding = Encoding.UTF8,
};
}
}
}
}
and add this filter to global filter atributes in global.asax

Answer 4

Repository level must have try-catch construction that handle sql exceptions and write errors to Log. If your business logic is complicated and can produce errors or inconsistent states - you should check it and write errors to Log too. If you want to notify user about something gonna wrong (if business logic provide exceptions) - you should use try-catch constructions in your controller actions and use ModelState.AddModelError(), as one of ways to notify user, or use other way to pass info about error into view. And finally you must have class CustomErrorFilter : IExceptionFilter registered in global.asax in Application_Start:
GlobalFilters.Filters.Add(new LoggingFilter());
That filter should write to Log all unhandled errors that occurs on controller level.
Remember about your code provide normal workflow and can provide error workflow (throw exceptions as one of ways to organize error workflow, or return some error codes). You should count on it and handle both workflows.