runtime hook for Crash on Error

[Jonathan M Davis]

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.

- Jonathan M Davis