My apologies if this is a simple question, but I don't think it is. :-)
I've noticed (although I don't have at the moment a case to demonstrate this) that occasionally my database will throw a warning (data truncation, IIRC). I take great care in my exception handling practices to wrap-and-throw, so that by the time any given exception burbles up to my J2EE application client, I have as much of the exception chain as is possible.
I've noticed that when the database throws a warning (recall that SQLWarnings are SQLExceptions) what I get on the client is a totally generic "the transaction rolled back" exception, and there is nothing in the stack to identify the root problem.
This makes a [i]certain[/i] amount of sense, because of course I don't necessarily have the database driver software (and hence the exception classes) on the client. But--and here's the question--I was wondering if there was some easy way to get the [i]stack[/i] of the server exception/warning to go all the way to the client. Am I missing something? Is it possible that Glassfish developers forgot to check SQLExceptions to see if they are, in fact, only SQLWarnings?
Laird
[Message sent by forum member 'ljnelson' (ljnelson)]
http://forums.java.net/jive/thread.jspa?messageID=225815