--- Comment #3 from Jonathan M Davis <> 2012-05-23 19:53:36 
PDT ---
Well, unstable behavior from an Error is pretty much a given if your program
doesn't die from it, unless it were treated completely like an Exception, in
which case you couldn't throw an Error (including OutOfMemoryError) from a
nothrow function, which would be unacceptable. Your program is pretty much
instantly in an unstable state as soon as an Error is thrown. It's just a
question of _how_ unstable, and the given implementation attempts far more
cleanup than is technically required according to Walter, which is a
double-edged sword, since that tends to make the code more stable when an Error
is thrown, but if your program is in a bad state thanks to whatever caused the
Error to be thrown, trying to do that cleanup could just make things worse.

Regardless, I completely agree that the situation needs to be clarified. We've
got the implementation going one way and Walter arguing another. And it would
certainly be better if it were guaranteed that finally and friends were never
executed when an Error is thrown than having them executed right now but
possibly not later when the implementation is tweaked. So, in principle, I
agree with the bug report, but as it stands, the current implementation is
within the required behavior.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to