Exception versus return code in DAO pattern

Question

After reading a lot about the abusive use of exceptions in Java and how you should let an exception bubble up through the different layers of an application, I've come to a point where I don't know what I am supposed to do with the potential errors my application can have.

Basically, I have a webservice which uses the DAO pattern to access data in my database. All of the database actions can throw a SQLException. As of today, I'm using a try catch to catch the SQLException and then thow a specific defined exception called ExceptionDAO that will be handle by the webservice to return a correct message to the users (a mobile application) of my webservice.

After reading a lot about how exception should be exceptional and should not be used in control flow, I've come up with a mixed understanding of what I should do to handle any errors:

• Use return codes for anything that is likely to happen (e.g. username already exists) and therefore, to comply with the DAO pattern, pass my business objects as parameters instead. I could also use a specific pair which would return the code + the business object instead. The webservice would then use the return code to display a specific message.
• Use checked exceptions for anything that I can't predict will happen and let them bubble up to the webservice to handle and return a message to the users. (e.g. SQLException that I can't predict : connection aborted)
• Let unchecked exceptions bubble up aswell and display a sort of 404 error in this case.

I also had a look at the null pattern but I don't think it suits this particular situation really well. I'm also concerned to not give too much information to the users, but rather useful and straight to the point information. Indeed, the messages returned by the webservice will be used by a mobile application to then display a message to the end-user.

I hope that I was clear enough about the problem I'm having, and I'm looking forward to your answers !

Answer 1

Return codes are suitable for C, which lacks exception handling among its features. For Java, please use exceptions, either checked or runtime, that's a matter of taste.

Personally, I hate checked exceptions, because they pollute my method signatures with information of border cases that might never occur. But maybe you want to be strict with the contract of your classes, even for such exceptional cases. If that's your case, then use checked exceptions. Otherwise, let your method signatures in peace and throw a runtime exception whenever you detect an exceptional case (such as an entity not found, entity already exists, etc).

Please note that ExceptionDAO is not a happy name. It appears to be a dao that handles exceptions. Maybe something like PersistenceException would be better.

Apart from that naming detail, I think your approach is on the right way, though not ideal. Ideally, you wouldn't need to do a try/catch for SQLExceptions inside every method that calls methods from your DAOs (or inside every method of your DAOs). Instead, a persistence exception translation mechanism would be much better. Spring, for instance, comes with one by default. Spring accomplishes this by proxying every DAO, and by letting its proxies perform a try/catch around every method invocation. Then, specific SQLExceptions with specific SQL error codes are translated to Spring's own DataAccessException hierarchy. So, in the upper layers, you would end up with a specific DataAccessException, but you wouldn't need to do a try/catch inside every method.

If you are already using Spring, then you have nothing to do, but if you aren't using it and have either many DAOs or many methods that might throw SQLExceptions, and all your DAOs implement an interface, then it might be worth the effort to implement a proxy that intercepts all the methods of your DAOs and performs a try/catch around them. Then, in this interceptor's catch block, you'd throw your ExceptionDAO (please rename it!) with a message that would depend on the original SQLException (and maybe on its SQL error code, too).

This approach has the advantage that you could handle all persistence exceptions in a single point of your program.

This very same concept could be applied to your web layer as well. Instead of letting every method of your endpoints handle your ExceptionDAO (don't forget to rename it!), you could create a proxy that intercepts every method call and perform a try/catch around it. You could then extract the message from the exception and send it in the response (or whatever you find suitable to do with it). Again, this is all based in Spring, this time, in Spring MVC Exception Handling mechanism. Here you could also handle unexpected exceptions, i.e. RuntimeExceptions and provide an appropriate message to your users.

The advantage, again, would be that you could handle all the exceptions that reached your web layer in a single point of your program.

Please see Proxy javadocs and this tutorial for further reference on Java's proxies.

Answer 2

I think you are missing an important option, which is the observer pattern.

In your DAO you can have this:

public interface OnExceptionInteractionListener {
    public void onExceptionInteraction(String exceptionMessage);
}

I would have the DAO be something like:

public SomeDAO(OnExceptionInteractionListener listener, ...) {
}

and I would instantiate the DAO as

SomeDAO s = new SomeDAO(new OnExceptionInteractionListener() {
  public void onExceptionInteraction(String exceptionMessage) {
  }
}, ...);

So, if there is an exception caught then call the listener in the DAO and the next level up will handle it.

This is better performance than throwing exceptions, and better than return codes.

For more on this you can look at this answer, for other examples: https://stackoverflow.com/a/18585099/67566

I haven't tried it but I expect that lambda expressions would be useful for this also, if you are using Java8.

Answer 3

Return codes are very old-school. Ideally, you should do your insert in some sort of transaction that checks:

1. Lock username inserts

2. Is this username available?

   3a. If so, insert and unlock

   3b. If not, unlock and inform user

If that's not possible, then a return object wrapping the result if it was created successfully and response Enum with potential outcomes.