runtime hook for Crash on Error

[Lars T. Kyllingstad]

On Wednesday, 6 June 2012 at 21:05:51 UTC, Jonathan M Davis wrote:
> On Wednesday, June 06, 2012 22:47:55 Lars T. Kyllingstad wrote:
>> On Wednesday, 6 June 2012 at 18:11:36 UTC, Jonathan M Davis 
>> wrote:
>> > On Wednesday, June 06, 2012 19:40:03 Lars T. Kyllingstad 
>> > wrote:
>> >> On Wednesday, 6 June 2012 at 09:38:35 UTC, Jonathan M Davis
>> >> 
>> >> wrote:
>> >> > On Wednesday, June 06, 2012 11:13:39 Lars T. Kyllingstad
>> >> > 
>> >> > 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.
>> >> > 
>> >> > But then instead of getting a nice, clear, 
>> >> > OutOfMemoryError,
>> >> > you get a
>> >> > segfault - and that's assuming that it gets dereferenced
>> >> > anywhere near where
>> >> > it's allocated.
>> >> 
>> >> "nothrow new" is easily greppable, though. That would be the
>> >> first course of action upon getting a segfault.
>> > 
>> > But unless you got a core dump, you have _no_ idea where in 
>> > the
>> > program the
>> > segfault occurred. So, that really isn't helpful.
>> 
>> Of course it's helpful. If you were using nothrow new (or
>> malloc, for that matter), you should *always* check its return
>> value. If you get a segfault, you simply locate all uses of
>> nothrow new in your program and ensure you have checked the
>> return value of each and every one of them. If it turns out 
>> they
>> are all checked, well, then the problem isn't OOM.
>
> But I do _not_ want to have to care about OOM. Having the 
> program throw an
> Error and kill the program when it occurs is _perfect_ IMHO. 
> So, if it were
> changed so that you could only allocate memory in a nothrow 
> function through a
> mechanism which did not throw OutOfMemoryError when you tried 
> to allocate and
> failed due to a lack of free memory, then nothrow would _suck_. 
> It would be
> extremely annoying to use, and completely cripple it IMHO.
>
> Having a mechanism which allows you to allocate without 
> throwing OOM is great
> for the cases where someone actually needs, it but I'm 
> _completely_ against
> requiring it anywhere.

You're probably right.  Besides, I just browsed through 
core/exception.d, and it seems that my list of Errors was far 
from exhaustive.  In addition to OutOfMemoryError, AssertError 
and RangeError, there is FinalizeError, HiddenFuncError, 
InvalidMemoryOperationError and SwitchError.  Working around 
nothrow for all of those would be painful.

SwitchError should probably be deprecated, by the way.

-Lars