Hello Paulex I have no objections against your changes. A check is always cheaper than exception.
I just wondered how a user code such as finalizer can affect VM like that, nothing more. 2006/5/23, Paulex Yang <[EMAIL PROTECTED]>:
> I have a question about this problem. Do you know how exception in > finalizer > method affects the finalizer thread that it becomes suspended? I thought > that when calling finalize method the code should catch all exceptions > thrown by it and ignore them. AFAIK that's how finalizers are > implemented in > DRLVM. It specification it is written that First of all, I think this issue should not happen if the spec of FileInputStream/OutputStream doesn't require the implementation to invoke close() in finalize() method, IMHO, generally it's not good practice to depend on finalize(), and I guess this spec is inherited from very early version, say, JDK 1.0, when the channel hasn't been not introduced. And actually I don't know exactly what happened to the finalizer thread when the NullPointerException thrown, because, as you know, the Harmony VME provided by IBM is only binary. What I saw is that the debugger sometimes stops on the suspending finalizer thread at the FileInputStream/OutputStream's close(), and the message shows that "NullPointerException caused suspending"(maybe not exact words, but very similar). So I tried to fix this problem in Java codes. And I'd glad to have a try on DRLVM later, but anyway, I think it is not bad idea to make our classlib codes more defensive and reliable. your ideas?
-- Gregory Shimansky, Intel Middleware Products Division
