Disallow catch without parameter ("LastCatch")

[Denis Koroskin]

On Wed, 28 Oct 2009 14:23:38 +0300, Christopher Wright  
<dhasenan at gmail.com> wrote:

> Denis Koroskin wrote:
>> On Wed, 28 Oct 2009 00:21:47 +0300, grauzone <none at 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.

OutOfMemory exception is supposed to be thrown with a call to  
onOutOfMemoryError(), that throws OutOfMemoryError.classinfo.init (i.e.  
global immutable instance of an Error).