runtime hook for Crash on Error

Lars T. Kyllingstad public at kyllingen.net
Wed Jun 6 13:47:55 PDT 2012


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.

-Lars


More information about the Digitalmars-d mailing list