[jira] [Comment Edited] (STORM-2028) Exceptions in JDBCClient are hidden by subsequent SQL-Exception in close()

["Rahul Jain (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/STORM-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16101917#comment-16101917 ] 

Rahul Jain edited comment on STORM-2028 at 7/26/17 4:54 PM:
------------------------------------------------------------

Hi [~RPCMoritz], Can I take up this one just to start as a fresh contributor. I might just follow up with the approach discussed in the description to log the connection closure and finally throwing the actual exception with appropriate message. Will also make sure to take care of the stack trace for the exception.


was (Author: cobracrowe):
Hi [~RPCMoritz], Can I take up this one just to start as a fresh contributor. 

> Exceptions in JDBCClient are hidden by subsequent SQL-Exception in close()
> --------------------------------------------------------------------------
>
>                 Key: STORM-2028
>                 URL: https://issues.apache.org/jira/browse/STORM-2028
>             Project: Apache Storm
>          Issue Type: Bug
>          Components: storm-jdbc
>    Affects Versions: 2.0.0
>            Reporter: Rick Moritz
>            Priority: Minor
>              Labels: newbie
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)