Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
2.0.0
Description
When an Exception is triggered in JdbcClient.executeInsertQuery there is the potential for a follow-up Exception in close() to take precedence over the previously thrown Exception, when triggered in the finally block. This makes debugging the actual Exception impossible.
As far as I can tell it would be better to catch the Exception form close() in the finally-block, and to combine it with the existing Exception, so that the key information for debugging purposes isn't lost.
For data consistency purposes we have to make sure that the Exception from closing the connection is thrown (or do we? can we be sure that a successful commit has persisted the data?) but "overlapping" Exceptions have to be dealt with.
Alternatively it might be a good idea to log the Exceptions before throwing them, so that the stack trace isn't lost. This is probably easier than tracking in the finally block whether a previous Exception has been thrown, and what to do with it.
If there's a workaround for this, that I might have missed, to get to the root of the Exception, I would also be interested in hearing, I'm currently looking at a situation where jdbc fails, and there being no indication of what's going on.
I labelled this newbie-level, since the implementation is pretty trivial; but the decision of which way to pursue isn't as clear to me.
Attachments
Issue Links
- links to
