[
https://issues.apache.org/jira/browse/DERBY-6722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152361#comment-14152361
]
Mamta A. Satoor commented on DERBY-6722:
----------------------------------------
DERBY-6724 ran into this issue where a NPE prevented us from knowing the actual
cause of the problem since NPE was not handled in
GenericStatementContext.cleanupOnError(). Fix for DERBY-6724 took care of NPE.
But, just to reproduce the the NPE on my client, I undid the fix for DERBY-6724
and ran the repro test attached to it and verified that NPE does not include
the original exception which caused the cleanup to start in the first place.
Then I changed GenericStatementContext.cleanupOnError() to handle unexpected
exceptions and reran the repro from DERBY-6724 and verified that now we chain
the original exception to NPE. I will go ahead and commit by changes to
GenericStatementContext.cleanupOnError(). Of course we can't use the repro from
DERBY-6724 for a junit test case for this jira because DERBY-6724 has been
fixed.
> GenericStatementContext.cleanupOnError() needs protection from later errors
> during statement cleanup
> ----------------------------------------------------------------------------------------------------
>
> Key: DERBY-6722
> URL: https://issues.apache.org/jira/browse/DERBY-6722
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.10.1.1
> Reporter: Rick Hillegas
> Assignee: Mamta A. Satoor
>
> If a statement raises an error and then a subsequent error occurs during
> statement cleanup, the original error is lost. This is discussed in this
> email
> thread:http://apache-database.10148.n7.nabble.com/NPE-from-InternalTriggerExecutionContext-cleanup-td141789.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
