Three-tier architecture and exceptions

Question

It's considered good practice to have an exception for each layer of application (i.e. PresentationException, ServiceException, PersistenceException etc). But what if my service-layer directly calls DAO methods (methods of persistence layer) without additional operations.

Like this:

public class MyService {
   private IPersonDAO dao = new PersonDAO();

   public void deletePerson(int id) { 
      dao.deletePerson(id);
   }

}

Should I wrap this DAO method invocation with a try-catch block and rethrow possible exceptions as ServiceException? Should each DAO method throw only PersistenceException?

Indefectible

How's your layers defined in application? If you have a Database layer then handle the exceptions at the DB layer instead of t he Service Layer. – Exact

Answer 1

Well your Dao exceptions are irrelevant to service layer and service layer has nothing to do with dao layer exceptions. Right approach would be to catch dao exception and rethrow new custom exception to service layer.

If you need to debug the exceptions and you want exact cause, you can use getCause() and getSuppressed() methods.

Should I wrap this DAO method invocation with try-catch block and rethrow possible exception as ServiceException? Should each DAO method throw only PersistenceException?

---> Yes wrap it. You can throw other exceptions from dao layer. See example below :

public class MyDao {       

   public Entity getMyEntity(int id) throws ObjectNotFoundException, PersistenceException {
      try {
         // code to get Entity
         // if entity not found then 
         throw new ObjectNotFoundException("Entity with id : " + id + "Not found.");
      } catch(Exception e) { // you can catch the generic exception like HibernateException for hibernate
         throw new PersistenceException("error message", e);
      }
   }

}

Annulet

hmm, why your method throws ObjectNotFoundException? Actually it can throw only PersistenceException. – Indefectible

even now it can throw only PersistenceException :). Need to add second catch block – Indefectible

when you read method name, you get an idea that this particular method throws these exceptions. Good and readable approach. And you can handle those. – Annulet

ok, so you mean I need to throw ONLY PersistentException from DAO layer, and throw only ServiceException from service layer. But what about ObjectNotFoundException you mentioned? It's really nice exception, and I think it can be thrown by service layer, because client really can to something when object is not found.. Not so? – Indefectible

So what about throwing ObjectNotFoundException to client? My service very similar to CRUD service, so I think it's meaningful to cause client to catch such exception. In other words what if my service layer will throw both ServiceException and ObjectNotFoundException – Indefectible

Well you can do so, make your service method throw both ServiceException and ObjectNotFoundException exceptions. I do so in my app. I handle exceptions in my controller layer using Exception handler and messaging. – Annulet

Answer 2

Yes. Its recommended, as you mentioned, to have exceptions for layers; as they can tell what's the problem from the service perspective instead of an DB.

Cobblestone

But methods of my service don't execute any additional operations. Because of my service method call only DAO methods, so there no chance to throw "true" service exception. All serivce exceptions in fact will be only rewrapped PersistentExceptions – Indefectible

Yes. But that would make sense as the presentation doesn't want to understand anything about DB. You can choose to wrap the DAO exception by your service exceptions, or just create an new servieexception which can inform what the user needs to know about the system. Also, throwing DAO exceptions to Presentation might even show some sensitive information to the user which he/she is not supposed to know. – Cobblestone

Answer 3

Yes, you should wrap those exceptions in any case, as your service layer clients would otherwise be forced to also deal with the database layer. This would make things overly complicated. Note that the bit of work required to be done in the service layer is meaningless small when compared to the work that would be required to deal with database exceptions in the layer above the service layer.

Rematch