0

What is the commonly accepted enterprise standard for Exception management?

Consider the project has three layer structure.

- Controller  
- Service throws ServiceException
- Dao throws DaoException

Is it right way to catch the DAO exception in Service layer and convert them to a Service exception?
Again catch the Service exception in Controller class and send a meaningful message to user without disclosing any business entities. Is this approach acceptable or should I allow DAO exception to pass to controller or any other thoughts??

Laiv
  • 14,283
  • 1
  • 31
  • 69
Arun
  • 119
  • 3
  • Catching DAO's exceptions in the service layer means that the service layer has a "plan b" to recover Itself form the error. Question is: can your services layer recover Itself from such sort of errors? – Laiv May 27 '17 at 09:52
  • Consider there is no planB. So you mean just pass the dao exception to controller? – Arun May 27 '17 at 12:42
  • Exceptions are not "passed " are just thrown or caught. You have to catch the exception where it makes more sense. If the business has nothing to do with the DAO's exception, you have to look at it as if it was a NullPointerException. Are you catching NullPointerException all over the project? I presume you don't. – Laiv May 27 '17 at 12:44
  • 1
    Where the runtimes exceptions go? That's a good question. Consider @SergeyShushlyapin answer to this concern: `All the unexpected exception should be handled in a centralized way in a single place. You may return some general error message to the user.` I usually do and it contributes (quite a bit) to make my code cleaner and readable. – Laiv May 27 '17 at 12:50

2 Answers2

2

There is a good practice is to throw early, catch late.

Is it right way to catch the DAO exception in Service layer and convert them to a Service exception?

On the ServiceLayer, instead of 'converting' an exception (and probably loosing some meaningful info) you would better re-throw the exception with advanced operation details. This will simplify further exception analysis since except the low level technical details from DAL there will be more high-level description of the initial intention.

catch the Service exception in Controller class and send a meaningful message to user without disclosing any business entities.

You should not rely on exceptions to steer your app flow. Exceptions are for exceptional situations. In the controller, instead of calling service API (and expecting an exception to return to the user) you can design your API in a way that will let you ask if an operation is allowed or not. If not then show a user error; if yes, just call the API.

All the unexpected exception should be handled in a centralized way in a single place. You may return some general error message to the user.

Serhii Shushliapin
  • 169
  • 5
  • 1
    Regarding the *throw early, catch late*. Take a look at the [why](https://softwareengineering.stackexchange.com/questions/231057/exceptions-why-throw-early-why-catch-late?noredirect=1&lq=1) – Laiv May 27 '17 at 12:52
-1

Exceptions should be reserved for exceptional situations - either something totally unexpected (i.e. a bug), or something which completely prevents your code from performing its function (e.g. your database is unavailable). In either case, this isn't something that a user can deal with and so I simply log as much information as I can and display a generic message to the user to let them know what the support process looks like (e.g. contact your administrator).

Don't have each layer throw its own type of exception - the only reason to create a new exception type is if you want to add more contextual information in the form of properties on the exception, or if you want to be able to catch that exception (which is very rarely - if your application is catching an exception its an indication that perhaps the exception is not all that exceptional).

I Don't catch an exception unless I can either:

  • Add information, e.g. if I'm processing a list of items I might catch all exceptions and rethrow a wrapper exception that includes information about the item being processed
  • Handle the exception, e.g. catch a specific exception that I know I can recover from (normally thrown by a 3rd party assembly), or in the outermost layers so I can log the exception and report an error to the user

If you catch and rethrow an exception be careful you don't loose any information which might help you diagnose the issue, especially the call stack. Catching and re-throwing all exceptions as a generic ServiceException is a surefire way to make bugs a lot more difficult to diagnose.

Justin
  • 1,728
  • 10
  • 16