Exception hierarchy design

Question

In my company we are building a webapp containing serveral central services that we design ourselves and then specify as interfaces. I.e. the interfaces are application specific and they are then implemented with third party libraries which we may change over time. When it comes to exceptions, I have realized that the exceptions thrown by our services should be our own application-specific exceptions as opposed to implementation specific exceptions.

Now, I am wondering how our exceptions should be structured and related to each other.

First, consider a generic exception MyAppException. This exception indicates that something unexcpected went wrong and the best thing we can do is to display a message to the user saying that something went wrong and that we are working on it. The error could be that the database crashed or something similair. This exception would pretty much be thrown from all methods working with the database.

Secondly, consider an exception MyAppDuplicateException. This exception would indicate that the user tried to save something into the database that was already there. Here, we can display a much more specific error message and this exception is only thrown from the methods that inserts or updates database rows.

The application can also contain other exceptions similar to MyAppDuplicateException for other excpected error situations. Ex MyAppNotFoundException etc...

Now to my questions:

1. Should the other exceptions extend MyAppException? I actually see no reason for this, I have just seen it in a lot of places and wonder if there is a purpose to it. The downside of this as I see it is that a try/catch-statement does not need to care about the specific exception in this case. It can just catch the top exception and because of this it does not need to handle the specific error which was pretty much the point of having the specific exception.
2. If the other exceptions does not extend MyAppException, should MyAppException be a java.lang.RuntimeException? This would not require executing code to catch it, which to me sounds natural since the point of the exception is to say that something unknown happened and the executing code is not excpected to be able to handle it. The code at the entry point of the request could still have a try/catch statement that catches MyAppException and makes sure that a message is displayed to the user.

edit There is no question if the specific exceptions like MyAppDuplicateException should be checked or not, the should defenetly be checked.

Answer 1

1. Sometimes you want to catch a specific type of exception (e.g. MyAppDuplicateException) and sometimes you want to catch a whole category of exceptions (e.g. MyAppException). By having MyAppDuplicateException extend MyAppException you're giving the calling code a bit more flexibility in how it deals with the different exceptions.
2. The best advice I've heard on this is that generally speaking you should throw a checked exception if whatever called your method obeyed its contract. It's a way of saying "here are the things that might be expected to fail". I would definitely make MyAppDuplicateException and the like checked exceptions (i.e. not RuntimeExceptions).

There's a very good article here which should help you avoid most of the common pitfalls.

Answer 2

I have realized that the exceptions thrown by our services should be our own application-specific exceptions as opposed to implementation specific exceptions.

By this you mean exceptions defined by your third-party implementation? Correct?

First, consider a generic exception MyAppException. This exception indicates >that something unexcpected went wrong and the best thing we can do is to >display a message to the user saying that something went wrong and that we are >working on it. The error could be that the database crashed or something >similair. This exception would pretty much be thrown from all methods working >with the database.

If this kind of exception represents an error in your program that is not caused by bad user input but rather some problem with your code, then in Java it should be a runtime exception.

Secondly, consider an exception MyAppDuplicateException. This exception would >indicate that the user tried to save something into the database that was >already there. Here, we can display a much more specific error message and this >exception is only thrown from the methods that inserts or updates database >rows.

This is a checked exception in Java.

If the other exceptions does not extend MyAppException, should MyAppException >be a java.lang.RuntimeException?

Yes.

This would not require executing code to catch it, which to me sounds natural >since the point of the exception is to say that something unknown happened and >the executing code is not excpected to be able to handle it. The code at the >entry point of the request could still have a try/catch statement that catches >MyAppException and makes sure that a message is displayed to the user.

Yes that's right.