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 !

N.B. : This a repost of a subject I posted on stackoverflow, which relates to programming and not a language specific problem.

Answer 1

On the conventional wisdom that states that you should only throw an exception when a condition occurs that you can't handle in your code we tend to focus on the definition of an exceptional condition but ignore the definition of what it means to handle the exception. A process may encounter a exception communicating with a particular node and may handle the exception by redirecting its request to a backup node instead. However, if a call to create an entry in a table fails because of a unique constraint as a result of a value entered by a user the only entity that can truly handle the condition is the user. Therefore this is grounds for throwing an exception as you cannot handle it in your code.

The semantics of your code also matters. Sticking with the example of creating a new user entry; a call to isAvailableUserName(userName) should not throw an exception if the userName already exists in the database whereas a call to createNewUser(userName) probably should. One reason to throw an exception instead of using a return code is that return codes in themselves provide inadequate information and require a lookup table or an enum that then becomes a dependency magnet. Exceptions on the other hand are more descriptive and contain a message, a backtrace, nested exceptions, etc. Exceptions also make your code cleaner. Instead of having lots of nested ifs that exist solely to test conditions, your code can function the way its supposed to and halt execution when a bad thing happens. Robert C. Martin in his book "Clean Code" states that error handling should not obscure the logic of the code. The cleanliness of the code also applies to the caller as return codes force the callers of the code to have to check for errors immediately after the call. Since this can easily be forgotten or ignored, its not a good approach. However, an exception cannot be ignored but must be handled.

Answer 2

You seem to have some misunderstandings about exceptions, so let's try and clear those up first.

Throw an exception when some condition occurs that you can't handle in your code.

For example, if your code is supposed to open a file and do something with that file, but the user supplies a path to a file that does not exist, then you should throw an exception (or allow a thrown exception to go up the call stack) because the user has created conditions by which your code cannot meaningfully continue to execute.

Rethrow an exception when you want to log or change the exception type.

For example, if you want to write the exception to a log or do something similar that does not correct the exceptional condition, catch the exception, log it, and then rethrow, perhaps with an exception that's more appropriate to your specific code.

A final thought: software guidelines and best practices are just that: guidelines. Respect them, but do the thing that is most appropriate for your specific situation. If that means breaking a guideline, then so be it. Don't let guidelines stand in the way of better programming. There are no absolutes in programming.