Look a little closer at Gregg's DAO implementation; he's already using the template class. The question still remains: whether a checked SQLException or an unchecked DataAccessException, what do you do with it?
My first maxim in catching and handling an exception is "Don't do it if you can't really handle it." The second is "If it's already unchecked, don't convert it or wrap it in another unchecked exception unless you can add something truly worthwhile."
For example, there are an endless number of non-system related events that can cause your application to throw an unchecked exception or error: your app runs out of memory (OutOfMemoryError) or a bug slips into production (IllegalArgumentException, NullPointerException, ArrayIndexOutOfBoundsException), etc. Regardless, you'll likely handle them exactly as you'd handle a DataAccessException: redirect to a generic error page telling the user to try again or come back on Tuesday.
Given that you'll handle them the same way, why bother wrapping DAException inside ServiceException? What does that add? The
servlet container, web framework, or event loop is going to catch all those with a single catch clause and take the same action each time. True, you might be able to determine from a DAException that the problem is likely to be temporary, but that's still an option with a raw DAException versus a ServiceException.
Long story short: let it propagate up the call chain for the controller to catch and handle unless it's part of your application's business logic. For example, maybe your website has the ultra-consumer-friendly policy that "If the payment system goes down, all customer orders are free." In that case you'd have to catch and parse the DAException in your business logic.
Now I've got a question for you. What's the difference between UserService and UserDao? UserService's API looks just like UserDao's. I inherited a similar design a couple years ago, only it took it to a new level: UserManager -> UserStore -> UserDao -> entity beans. The signatures and exception names were different at each layer, but the
pattern they formed was identical. This required a lot of redundant code as each layer had to repackage objects and translate exceptions for the other layers.
Worse still, all of the business logic was in the
Struts Action classes. This proved to be quite inflexible and difficult to maintain or extend. However, I've seen this pattern more than a few times.
My belief is that the business logic layer (UserService in your example) should use the DAO layer but not mirror it. It should provide an expressive business-oriented API rather than a form of CRUD that differs only slightly from the DAO's. Granted, it's still common in today's applications to present the user with a set of fields, let them change some, and shoot them off to the database. Yes, you'll still have some of those, but I feel they run counter to OO design and should be avoided when possible.
In any case, I was just curious to know your thinking. Of course, I'm extrapolating from a very small example and could easily be mistaken. Whatever your UserService layer looks like, I highly recommend against putting the business logic in the presentation layer. You'll duplicate a lot of code and paint yourself into a corner. You'll also double the probability that your next assignment will be to create a thin yet comprehensive web services layer.
A good book on this topic is Domain Driven Design. Hmm, that reminds me ... I got side-tracked and didn't finish the book. Guess I'll have to pop it up the stack a few levels.