runtime hook for Crash on Error

[Lars T. Kyllingstad]

On Wednesday, 6 June 2012 at 13:26:09 UTC, Steven Schveighoffer 
wrote:
> On Wed, 06 Jun 2012 05:13:39 -0400, Lars T. Kyllingstad 
> <public at kyllingen.net> wrote:
>
>> On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer 
>> wrote:
>>> On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky 
>>> <dmitry.olsh at gmail.com> wrote:
>>>
>>>> I don't agree that OutOfMemory is critical:
>>>> 	--> make it an exception ?
>>>
>>> No.  What we need is a non-throwing version of malloc that 
>>> returns NULL.  (throwing version can wrap this).  If you want 
>>> to throw an exception, then throw it there (or use enforce).
>>
>> With some sugar:
>>
>>     auto a = nothrow new Foo; // Returns null on OOM
>>
>> Then, ordinary new can be disallowed in nothrow code.
>
> That doesn't work, new conflates memory allocation with 
> construction.  What if the constructor throws?

The constructor would have to be marked nothrow as well.  
Actually, that is currently the case:

     class Foo
     {
         this() { }
     }

     void bar() nothrow
     {
         auto f = new Foo;
         // Error: constructor this is not nothrow
         // Error: function 'bar' is nothrow yet may throw
     }

The only difference between "new" and "nothrow new" is that the 
latter would return null on allocation failure instead of 
throwing an OutOfMemoryError.

Based on this discussion, I gather that one of the big problems 
is that the compiler is free to elide stack unwinding code for 
nothrow functions, despite the fact that they can in fact throw 
Errors.  One solution would therefore be to disallow *all* 
throwing from nothrow functions, including Errors.

Besides OutOfMemoryError, I can only think of two other Errors 
that would make this a hassle: AssertError and RangeError.  
However, both of these signify problems with the program logic, 
and unwinding the stack is probably a bad idea anyway, so why not 
simply make these abort()?

-Lars