Alexey Varlamov wrote:
> 2006/11/15, Gregory Shimansky <gshimansky@gmail.com>:
>> Alexey Varlamov wrote:
>> > The guilty change is the following, which effectively turns on
>> > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>>
>> Well this is a patch from HARMONY-2018 which doesn't hide the fact that
>> it enables lazy exceptions. Why shouldn't we enable them?
>
> The point is not that we should or should not enable them, rather the
> fact that the regression appeared due to this change. I just tried to
> localize the problem hoping it will help to resolve this regression
> soon instead of reverting.
>
>>
>> Actually if you revert the patch (I've tried) this doesn't seem to fix
>> the test. At least the exceptions are still there, not sure about test
>> PASSED status.
>
> Verbose test output is confusing but itself does no harm. I found so
Ah this explains it. When I tried to investigate the regression I've
reverted the patch and tried the test alone. I saw exceptions and
thought that the test failed. I didn't realize that it is just an output.
> far the following:
> 1) the test fails on this assertion (ClassGenericsTest4.java:799):
> if (!(e.getCause() instanceof
> java.lang.reflect.GenericSignatureFormatError)) {
> fail("test_3, case 003 FAILED: GenericSignatureFormatError should
> be risen.");
> }
> because of e.getCause() returns null. That is, lazy machinery drops
> the cause of InvocationTargetException, I did not yet figured out why.
I see. If the problem appears to be hard to solve we should revert the
HARMONY-2018 patch.
> 2) Test report provides the following diagnostics:
> java.lang.NullPointerException at
> junit.framework.TestCase.runTest(TestCase.java:168). This seems to
> point to the same problem: lost cause exception after reflection.
--
Gregory
|