[
https://issues.apache.org/jira/browse/DERBY-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688688#action_12688688
]
Tiago R. Espinha commented on DERBY-3911:
-----------------------------------------
Interestingly enough, by changing the return statement into the finally block
on Kathey's example, we still get the NPE and the code doesn't return
successfully.
I think it remains a mystery to why this was happening in the first place on
the original case. Even having the exception happening inside the finally
block, the last exception to happen (and to not be caught) should stop the
thread it is executing on, right?
> BTreeController.reclaim_deleted_rows() may hide exceptions
> ----------------------------------------------------------
>
> Key: DERBY-3911
> URL: https://issues.apache.org/jira/browse/DERBY-3911
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.5.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3911.diff
>
>
> BTreeController.reclaim_deleted_rows() contains this piece of code:
> catch (java.lang.ClassCastException cce)
> {
> // because we give up the latch on the leaf before entering this
> // routine, the page might change from a leaf to branch. If that
> // happens this routine will get a ClassCastException, and we
> // just give up trying to reclaim space.
> }
> finally
> {
> if (controlRow != null)
> controlRow.release();
> return(purged_at_least_one_row);
> }
> It intentionally hides ClassCastExceptions, but it also unintentionally hides
> all other exceptions because of the return statement in the finally clause.
> Some related discussions can be found in DERBY-3216 and DERBY-3905.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
