It looks to me like a hack to get around a bug in the caller, ie.
calling getScanInfo() on a closed conglomerate.
Usage documentation for GenericScanController.java!close in
java/engine/org/apache/derby/iapi/store/access/GenericScanController.java
says that controller should not be used after close().
To my knowledge this interface is only used to print out interesting
stuff to runtime statistics, so silently providing as much info as
possible was probably considered better than failing a query. Did
you run full set of tests and only saw one error - or was that just
one of many?
Kristian Waagan wrote:
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,
