Handling Dao exceptions in service layer

Question

If my Dao layer throws Dao specific exceptions, then does handling them in my service layer consitute a leakage of concerns? If yes, then should I make the exceptions generic and independent of any layer to address it, or is there some other way?

The same question is applicable to UI layer handling exceptions thrown by service layer.

Solution 1

When we create a layered application, there is always a user layer and another used layer. For this case UI layer -> uses service Layer -> uses DAO layer.

Now its very subjective and open to interpretations. But the objective should be a good degree of decoupling. To achieve this, one way out is the define generic layer specific exceptions say PersistentException, ServiceException etc. These exception will wrap the actual layer specific exception.

For example say if there is some error on database side (Constraint violation etc), wrap that in PersistentException and let service layer handle that (as to how to convey this to UI layer in a generic way)

Now since the integration between service layer and DAO layer is contractual (interface based), the DAO layer is free to change the implementation to anything as long as it obeys the interface contract. So if you change the implementation which throws some new exceptions, those new exceptions can be wrapped in PersistentException and Service layer remains unaffected.

Solution 2

Yes. its a good idea to create your own independant exceptions for each layer.

For example, if you are using a particular DAO implementation, you should wrap the implementation specific exception to your own generic exception and throw it forward to Service Layer.

However, you need to be sensitive in creating your own hierarchy of exception such that it shouldn't be an overhead to application development as well as its able to maintain the information required in the Service Layer. Most of the times, custom error codes with generic exception suffice this.

Something like this can be used to simulate implementation specific exception and thrown to Service layer.

class AppDAOException extends Exception {
    public final static int _FAIL_TO_INSERT = 1;
    public final static int _UPDATE_FAILED = 2;
    public final static int _SQL_ERROR = 3;
    private int errorCode;
    public AppDAOException(int errorCode) {
        this.errorCode = errorCode;
    }
    public getErrorCode() {
        return errorCode;
    }
}

Throwing from DAO implementation:

try {
   //code here
} catch (some.impl.SQLSyntaxException e) {
   throw new AppDAOException (AppDAOException._SQL_ERROR );
}

About leakage of concern: You may not want your service layer to bother about all the exceptions - such as:

} catch(NoRowExistsException e) {
    return null;
} finally {
   //release resources
}

So the call has to be taken based on application needs.

Solution 3

Your DAO layer already leaks into the service layer when you do operations like:

userDAO.persist(user);

Exceptions, being a part of the API just like operation should be considered in the same way.

try {
    userDAO.persist(user);
} catch (DAOException e) {
    // looks fine to me
}

Leakage can happen with runtime exceptions, or when you rethrow exceptions

try {
    userDAO.persist(user);
} catch (SQLException e) {
    // sql implementation exposed
}

But even this sounds better than "layer independent" exceptions

Comments

[shrini1000]

thanks for the answer, but I'm still not clear if handling Dao exceptions in service layer constitutes a leakage of concerns and if yes, then how to handled that.

[Ved]

leakage of concerns means?? DAO specific exceptions even though handled in service layer or DAO layer itself may not be a concern.

[shrini1000]

what I mean is this: Dao exceptions may contain in them information that is specific to Dao issues; now if the service layer has to process this information in order to handle the exceptions, won't service layer get tightly coupled with Dao layer? so won't that constitute a leakage of concerns from Dao to service?

[Ved]

Ya may be. but only when processing the information consists the major changes.

[Shantaram Tupe]

could you please provide an example of this ...thank you

[Santosh]

I wrote a post on this sometime back. Please check dzone.com/articles/quotdecouplingquot-the-exception-puzzle

[Java Main]

@Santosh in your article above,you are duplicating the log while the execption is bubbling up. So this is bad practice

[Santosh]

@JavaMain, can you please put this comment against that article? I will put by response over there.

[Java Main]

Sure i will do .