need some advice...I am fully aware that Validation/Syntax Checking, etc. should happen above the Data Access Layer. However the powers that be would like the DAOs to do an extra check. Should when this Checked Exception extend Exception, not be coughed and handled later up? or should I catch this exception and rethrow as a DAOException…. my thinking is that this is no a "DAO" Exception but a validation/syntax type exception and should not be caught and rethrow....

Current architecture pattern:


so in this example, I don't catch the DenyQueryException and let the Service tier, or Resource Tier(JAX-RS) handle this?:

public FooDAOImpl {
   public List<Foo> query(String queryStatement) throws DAOException,DenyQueryException{           
              db.findBy..(queryStatement) ){
              catch(SQLException e){
                    throw new DAOException(e);
public class DenyException extends Exception{

or, have this DenyQueryException caught and rethrown as a DAOException(..)

public FooDAOImpl {
   public List<Foo> query(String queryStatement) throws DAOException {           
              }catch(DenyException e){
                    throw new DAOExceptoin("query statement contains illegal text.",e);
              catch(SQLException e1){
                    throw new DAOException(e1);
public class DenyException extends DAOException{
  • Am I correct in assuming a DAOException is from iBatis? Aug 13, 2020 at 19:52
  • no, the DAOException Is a custom checked exception implemented for application.
    – Jeryl Cook
    Aug 13, 2020 at 21:28
  • Ok. I will update my answer tomorrow. Aug 14, 2020 at 0:52

2 Answers 2


If some architect decided that all exceptions coming from a DAO should be DAOExceptions, I'd not extend the throws clauses with additional exception types. So, the options remain to have DenyException extend DAOException or wrap it in a plain DAOException.

Control-Flow Aspects

For the "extending" solution, I only see a very questionable "benefit", being that at some higher level some code might explicitly catch that exception type and act upon that.

  • If that "acting upon" only means logging and informing a user, I doubt that it's worth the effort. A well-written exception message does the same job then.
  • If it means that some code knows an automatic way how to turn the failure into a success, then of course that code needs enough information to decide on the correct reaction, and then the exception type might be part of the solution. But most probably, a whole bunch of context information has to be included in the exception to make that happen. (And, will this fall-back solution really apply to all situations where this exception type is thrown?)

Typically, for control-flow purposes, callers are only interested whether the call succeeded or failed, and for this aspect any type of exception does the job.

Logging / Informing Aspects

For logging purposes, it's important to include information that helps an administrator to analyze the problem and decide on appropriate actions. And if the admin then needs developer assistance, this one probably needs additional info, most prominently the stack trace. All this can be done without any special exception class hierarchy.

Informing the user is a different story. He isn't interested in technicals details (and maybe you don't want to disclose your internals...). He typically just wants to know

  • that his request failed,
  • if there is something he can do to make it eventually succeed. (I think we all know e-commerce sites showing us PHP line numbers or SQL syntax error messages.)

If your project's existing exception architecture supports that aspect, follow the established rules. If not, any exception type will do the job. Even showing a class name like DAOException is "too much information" for the average user.


Use the cheapest way of fulfilling the general contract, and that is wrapping any upcoming exception in a DAOException, and make sure the message contains all necessary information for logging, debugging (and maybe informing the user).

Having a detailed exception hierarchy falls into the YAGNI category.


If you are going to throw an explicit exception in your data access layer, keep in mind the semantic meaning of that exception. This should be reflected in its type. Also bear in mind where this exception will get caught. I would recommend hiding data access implementation details from the exception type.

If your data access layer is meant to abstract away a SQL database, then I definitely would not want SQLException in the method signature. Instead, wrap it in something more meaningful, but not specific to how data is stored.

I would go for InsecureQueryException or something more generic like SecurityException to communicate the query would have been a possible security issue.

If DAOException is from iBATIS, then I would be reluctant to even mention this type in the method signature. The specific kind of data mapper you are using is an implementation detail of your data access layer. I would have your exception extend a more abstract type, like Exception:

Exception -> SecurityException


Exception -> InsecureQueryException

Just imagine if you need to switch this part of the data access layer to a web service or document database like MongoDB. I wouldn't want a potentially dangerous query to be sent to those data stores either. If iBATIS cannot be used, then your custom exception would not be extending DAOException.

The challenge with any Type for exceptions is to communicate enough to debug, but not so much you need to refactor a bunch of code when internals change.

  • "If you are going to throw an explicit exception in your data access layer" im asking should I throw an explicted exception....or just add it to DAOException.
    – Jeryl Cook
    Aug 13, 2020 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.