db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Suspectible swallowing of AssertFailure in BTreeScanInfo
Date Thu, 15 Mar 2007 13:17:37 GMT
Hi,

Work in the access layer revealed something I find a bit disturbing, at 
least with the way the code looks today. In the constructor of 
impl.store.access.btree.BTreeScanInfo:

         try
         {
             stat_treeHeight = scan.getHeight();
         }
         catch (Throwable t)
         {
             stat_treeHeight = -1;
         }

I didn't understand why Throwable was caught and ignored, so first I 
tried to change it to StandardException. This caused the test 
ddlTableLockMode to fail.  I looked at what was going on, and found this 
to be thrown from the code above (code modified to print the Throwable):

*** Start: ddlTableLockMode jdk1.5.0_11 2007-03-15 13:53:12 ***
48a49,52
 > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED 
ControlRow.Get() is being called on a closed container.
 > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED 
ControlRow.Get() is being called on a closed container.
 > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED 
ControlRow.Get() is being called on a closed container.
 > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED 
ControlRow.Get() is being called on a closed container.
Test Failed.
*** End:   ddlTableLockMode jdk1.5.0_11 2007-03-15 13:53:21 ***

As I said, I find this a bit disturbing. Can anyone with knowledge of 
this part of the code shed some light on this?

Specifically:
  a) Is this expected behavior?
  b) Can you add a descriptive comment for the catch block?
  c) Should the catch block be more specific, and maybe check for the 
expected assert failure?



thanks,
-- 
Kristian

Mime
View raw message