Java Throwing exceptions vs returning response in catch

Question

I know a lot has been discussed around exception handling, however I need some advice specific to my situation.

I am currently working on a Spring MVC application with Controller->Services->DAO layers. The service classes catch mainly two kinds of exceptions HibernateException and IOException.

HibernateException because service needs to perform rollback if a transaction did not succeed and IOException since it is an unchecked exception and needs to be caught or thrown and I prefer the first option.

Now what would be a better way of handling these further up in the stack :

1. Should I rethrow these exceptions to the controller and in the ExceptionHandler of the controller send a HTTP error-code 500
2. Or in the catch block create the normal JSON response object, setting status=failure and the appropriate error message and return this to the Controller?

Answer 1

Exception Handling convensions:

There is a saying that, best way of handling Exception is not to handle it!

For Spring's convention of controller<->service<->dao layers, Exception handling mechanism is known as Bubble up. Any exception occurs in the dao or service layer, you should pop it up to the controller layer (by adding throws XXXException in dao and service layer's method signature, is the most common way). Only controller layer should handle Exceptions.

Here is a nice tutorial of how you can handle exceptions for REST with spring.

Send HTTP Status code 500 or JSON object with status:

Sounds like you are writing API with Spring MVC. Look, when you are writing API's you should follow the proper conventions. It is Globally accepted that for internal server errors you send HTTP response with code 500, that means internal server errors.

There are number of causes for what you should not send JSON response in this case. One of the main cause is the implicit assumption of your API client. That is HTTP response with code 200 with a JSON object means every thing went normal. And thus the client side business logic may reflect that assumption which is wrong eventually.

Here you can see some API error code conventions for some well-known organizations:

• twitter
• LinkedIn
• Facebook Graph API

Answer 2

I assume that you have not come so far yet as to create a client and therefor can pick 100% for yourself.

If so I would also recommend to use 1, for the main reason that using the correct status codes can go a long way in your API, as well as it's a very easy solution to your problem. You can write some neat code for your error handling. Another major reason why you should use your first point is because you can easily re-use the error handling for other APIs, resources or webapps.

For example an enum with all your errors, and what status code you consider them to be, and you can also include what log level you want them to be.

public enum ExceptionMapping {
IllegalArgumentException(IllegalArgumentException.class, 400, LogLevel.ERROR),

If your goal is to build a neat API for unknown clients I would recommend reading more about REST level 3 (http://martinfowler.com/articles/richardsonMaturityModel.html) where you includes hypermedia links to create an API which allows the client to "browse" your full API. It's more work for the client since they have to be smarter but it can provide you with very nice features such as breaking a large part of your API without the client even noticing.