Exception Handling Methods

[gdboling]

I've searched this forum and found bits and pieces on what I was looking for but nothing definative.

I am curious as to where I should be throwing and catching database type exceptions. For example, I have a DAO interface and it's implementation. Then I have a service interface and it's implementation which uses said DAO.

So in which layer do I catch/throw my exceptions? Should the Service method(s) throw an exception? Should the DAO method(s) throw an exception which are caught by a try/catch in the service method which uses the DAO?

Also, before using Spring, we were sending the SQLException's getErrorCode() to our own PersistenceException. DataAccessException doesn't have a getErrorCode method, so what is the best way to retrieve that, if any.

Thanks.

[Alarmnummer]

Most database exceptions are considered unrecoverable and that is why they are Runtime. Making an exception runtime doesn't force you to deal with them, but they can travel down the call stack (first call is on the bottom, last call on top)

The layer on top of the service layer should 'deal' with the exceptions. If I use Spring-MVC the runtime exception is caught and an error screen is shown.

[gdboling]

Most database exceptions are considered unrecoverable and that is why they are Runtime. Making an exception runtime doesn't force you to deal with them, but they can travel down the call stack (first call is on the bottom, last call on top)

The layer on top of the service layer should 'deal' with the exceptions. If I use Spring-MVC the runtime exception is caught and an error screen is shown.

Thanks. I understand that exceptions are mostly unrecoverable. As for the layer above the service layer, that makes sense. So the question now becomes, how far down should I be throwing the exceptions in order for the layer above the service layer to have the information it needs to display to the user? Should the Service layer methods throw an exception?

public List<Category> getCategory(final Integer catId) throws DataAccessException;

Or do I not even have to do that.

Thanks.

[Alarmnummer]

Thanks. I understand that exceptions are mostly unrecoverable. As for the layer above the service layer, that makes sense. So the question now becomes, how far down should I be throwing the exceptions in order for the layer above the service layer to have the information it needs to display to the user? Should the Service layer methods throw an exception?

public List<Category> getCategory(final Integer catId) throws DataAccessException;

Or do I not even have to do that.

Thanks.

Well.. documentation is a good thing.

My business layer only throws checked exceptions for 'business related problems' like: UserAlreadyRegistered.

[Andrew Swan]

... before using Spring, we were sending the SQLException's getErrorCode() to our own PersistenceException. DataAccessException doesn't have a getErrorCode method, so what is the best way to retrieve that, if any.

The beauty of Spring's DataAccessException hierarchy is that it provides a handy abstraction from the vendor-specific error codes reported by different JDBC drivers. Your "tier above the service tier" only needs to check which specific subclass of DataAccessException has been thrown; it doesn't know or care which db product is actually being used.

If you wanted to retain your PersistenceException class, perhaps you could modify its constructor (or its factory, if it has one) to take a DataAccessException as a parameter (at which point it could do whatever it needed with it).