Message9651

>FinalizeTrigger#finalize should suppress the exception - printing it to stderr - instead of throwing Throwable.

Exceptions are currently not printed to stderr, but *should* already be suppressed. Doc of java.lang.Object#finalize() states:

If an uncaught exception is thrown by the finalize method, the exception is ignored and finalization of that object terminates.

and

Any exception thrown by the finalize method causes the finalization of this object to be halted, but is otherwise ignored.


Of course we can try whether it makes a difference, but according to these lines from the doc it should not. (Printing the exception to stderr should be added to match CPython behavior though.)

I guess the exception is somehow stored in the current ThreadState's exception-field (via Py.setException(...) ?), bypassing the ignore-exceptions-from-finalizers strategy of Java's gc-thread.

So removing "throws throwable" from FinalizeTrigger#finalize would probably not fix it. I think the finalize trigger would have to look at
ThreadState#exception, print it and clear it before it returns. Otherwise the exception is not entirely suppressed from Jython's point of view.

I'd suggest to write a minimalized test for this (as opposed to running the entire Sphinx test suite) to pin the issue and verify the fix without additional blur. However I won't find time for this before sunday.

On the other hand it should be quested why ZipFile.__del__ causes a NullPointerException anyway. Looks like a bug for me. Iff this is normal behavior (in an exceptional case though), shouldn't the exception be something more Python-like?
Something like TypeError or ValueError complaining something is None that shouldn't be? This should be investigated by someone familiar with the zipfile module.

Taking a quick look at zipfile.ZipFile code, there is this suspicious line in the class-body:
fp = None                   # Set here since __del__ checks it
But __del__ (i.e. close()) only looks at self.fp. So maybe the line should be in __init__ and read self.fp = None. However __init__ actually seems to init self.fp to *something* in any case. So I don't think this causes the issue, but it is still weird.