Question

I have this sort of format

asp.net MVC View -> Service Layer -> Repository.

So the view calls the service layer which has business/validation logic in it which in turns calls the Repository.

Now my service layer method usually has a bool return type so that I can return true if the database query has gone through good. Or if it failed. Then a generic message is shown to the user.

I of course will log the error with elmah. However I am not sure how I should get to this point.

Like right now my Repository has void return types for update,create,delete.

So say if an update fails should I have a try/catch in my repository that throws the error, Then my service layer catches it and does elmah signaling and returns false?

Or should I have these repository methods return a “bool”, try/catch the error in the repository and then return “true” or “false” to the service layer what in turn returns “true” or “false” to the view?

Exception handling still confuses me how handle the errors and when to throw and when to catch the error.

Answer 1

The rule of thumb I always use is:

• At low levels, throw when an operation cannot complete due to exceptional circumstances.
• In middle layers, catch multiple exception types and rewrap in a single exception type.
• Handle exceptions at the last responsible moment.
• DOCUMENT!

Here’s an example in pseudocode for a multi-layer ASP.NET MVC app (UI, Controller, Logic, Security, Repository):

1. User clicks submit button.
2. Controller action is executed and calls into the Logic (business) layer.
3. Logic method calls into Security with the current User credentials
   • User is invalid
     • Security layer throws SecurityException
     • Logic layer catches, wraps in LogicException with a more generic error message
     • Controller catches LogicException, redirects to Error page.
   • User is valid and Security returns
4. Logic layer calls into the Repository to complete action
   • Repository fails
     • Repository throws RepositoryException
     • Logic layer catches, wraps in LogicException with a more generic error message
     • Controller catches LogicException, redirects to Error page.
   • Repository succeeds
5. Logic layer returns
6. Controller redirects to the Success view.

Notice, the Logic layer only throws a single exception type — LogicException. Any lower-level exceptions that bubble up are caught, wrapped in a new instance of LogicException, which is thrown. This gives us many advantages.

First, the stack trace is accessible. Second, callers only have to deal with a single exception type rather than multiple exceptions. Third, technical exception messages can be massaged for display to users while still retaining the original exception messages. Lastly, only the code responsible for handling user input can truly know what the user’s intent was and determine what an appropriate response is when an operation fails. The Repository doesn’t know if the UI should display the error page or request the user try again with different values. The controller knows this.

---

By the way, nothing says you can’t do this:

try
{
  var result = DoSomethingOhMyWhatIsTheReturnType();
}
catch(LogicException e)
{
  if(e.InnerException is SqlException)
  {
    // handle sql exceptions
  }else if(e.InnerException is InvalidCastException)
  {
    // handle cast exceptions
  }
  // blah blah blah
}