Re: You didn't answer the question ...
Wrapping exception is used to create a facade to the next layer. So, since SQL exceptions are checked, I can do one of two things: I can wrap them and rethrow them as application-specific checked exceptions, or I can rethrow them as unchecked exceptions. For SQL exceptions, I've seen both. Personally, I usually wrap them in checked exceptions because I like to associate a prettier error message with them as close to where it happens (I have more contextual information at that point). Then, I have a simple application-specific checked exception that the higher layer (say the presentation layer) can deal with in a generic, simple fashion (in some cases, the higher layer may not even need to know anything about the exception because it contains enough information for display purposes, but that's dependent upon the application type and how it's designed).
I approach unchecked exceptions in this way: if it's a programmer's error (i.e. a null pointer exception or something like that), an error (i.e. out of memory), or something that can't be handled and dealt with at a lower level (because the contextual info isn't helpful, or it doesn't make sense to), then using unchecked exceptions works well. However, if it's a application exception, such as bad input from the user, database going down (and this one can go either way...it depends upon the interface to the user), etc. then checked exceptions are nice because they can usually be handled nicely by the upper layer.
Hope that answers your question.
Dan
