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.

Santosh · Accepted Answer · 2013-09-02T03:58:45.127

37

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.

edited Sep 02 '13 at 03:58

answered Feb 13 '12 at 07:29

Santosh

17,667
4
54
79

could you please provide an example of this ...thank you – Shantaram Tupe Sep 16 '17 at 11:18
I wrote a post on this sometime back. Please check https://dzone.com/articles/quotdecouplingquot-the-exception-puzzle – Santosh Sep 18 '17 at 11:22
@Santosh in your article above,you are duplicating the log while the execption is bubbling up. So this is bad practice – Java Main Jan 04 '19 at 10:01
@JavaMain, can you please put this comment against that article? I will put by response over there. – Santosh Jan 11 '19 at 13:32
Sure i will do . – Java Main Jan 14 '19 at 12:47

score 9 · Answer 2 · answered Feb 13 '12 at 06:59

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.

score 6 · Answer 3 · answered Mar 27 '12 at 20:11

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

score 0 · Answer 4 · answered Feb 13 '12 at 06:21

0

Good question..!! Handling exceptions at the UI layer (for example, actions layer if you are using struts) is the good approach.Making exceptions generic is not a good way to deal with this issue. Every layer should have however their specific exceptions as generic. for example, DAO layer may have custom exception handlers like DavaSavingException, IOException etc..

So the approach is throw exception from DAO to service layer and again throw it to UI layer and catch in UI specific classes.

However things are too diplomatic depending upon your applications/needs.

answered Feb 13 '12 at 06:21

Ved

8,577
7
36
69

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. – shrini1000 Feb 13 '12 at 06:44
`leakage of concerns` means?? DAO specific exceptions even though handled in service layer or DAO layer itself may not be a concern. – Ved Feb 13 '12 at 06:49
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? – shrini1000 Feb 13 '12 at 06:55
Ya may be. but only when processing the information consists the major changes. – Ved Feb 13 '12 at 07:01

Handling Dao exceptions in service layer

4 Answers4

Linked