Disallow catch without parameter ("LastCatch")

Max Samukha spambox at d-coding.com
Wed Oct 28 03:00:46 PDT 2009


On Wed, 28 Oct 2009 02:12:12 +0300, "Denis Koroskin"
<2korden at gmail.com> 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.
>
>QtD did just that last time I've checked.

The "or other allocation mechanism" part is important. If an
allocation on GC heap has failed, it doesn't make sense to allocate
the exception object there. But in the case of malloc, the program may
still be able to allocate the exception object and try to recover if
it makes sense. So I don't think the code is all that amusing.



More information about the Digitalmars-d mailing list