Kevin Marcus wrote:Folks- I'm actually a bit bewildered by all the wonderful sub-classes for DataAccessException. I know I shouldn't but I almost miss the bad ol' good for nothing SQLException. Here is the situation:
Let's say I'm trying to insert (using SimpleJDBCTemplate) a record. What and how many of the specific Exceptions should i try to catch(){}?
Fact of the matter is, I'll end up enveloping that exception into a more general exception and throw it upword (towards the service layer).
Same for other CRUD operations.
Thanks for the replies.
Exactly. That is why you want DataAccessException, because you don't want to catch exceptions just so you can wrap it and throw a more general exception and have that type of code in all layers. Instead you only catch DataAccessExceptions that you can actually do something about, something you can actually handle and correct, you the user in those scenarios never see an exception. Or in some cases allow the user to see a better message about what actually occurred. For instance, only catching a OptimisticLockingException, can you send the message "Oops, we are really sorry, but someone beat you to saving that data. Please try to re edit the data and re-submit." I wouldn't send that message if there was a ConstraintViolationException through.
And now that you converted to DataAcessExceptions which are uncheck exceptions, means you don't have to catch squat in your Repository layer. That is mostly how I roll. The least amount of try/catch es I can have in my code, way the better.
Mark
