Denis Koroskin wrote:
On Wed, 28 Oct 2009 00:21:47 +0300, grauzone <n...@example.net> wrote:
BCS wrote:
Hello grauzone,
PS: I wonder, should the runtime really execute finally blocks if an
"Error" exception is thrown? (Errors are for runtime errors, Exception
for normal exceptions.) Isn't it dangerous to execute arbitrary user
code in presence of what is basically an internal error?
If a thrown Error doesn't run finally blocks you will have a very
hard time arguing for catch working and once those don't happen it
might as well kill -9 the process so why even have it in the first
place?
You still can use a "catch (Throwable t)" to catch all kinds of
errors. I just think that finally (and scope(exit)) should be designed
with high level code in mind. Code that allocates heap memory in a
finally block is already broken (what if an out of memory error was
thrown?).
I've seen code that has throws new OutOfMemoryException(__FILE__,
__LINE__); when malloc (or other allocation mechanism) has failed, and
it always make me smile.
Maybe the GC should reserve a small amount of space (~1KB) for its
exceptions, when memory is tight.
