Exception/Error division in D

Sean Kelly sean at invisibleduck.org
Wed May 30 19:06:44 PDT 2012


On May 30, 2012, at 5:58 PM, "Kapps" <opantm2+spam at gmail.com> wrote:

> On Wednesday, 30 May 2012 at 22:22:01 UTC, Jonathan M Davis wrote:
>> On Thursday, May 31, 2012 00:01:16 deadalnix wrote:
>>> Most segfault are null deference or unintizialized pointer deference.
>>> Both are recoverable.
>> 
>> If you dereferenced a null pointer, it's a bug in your code. Your code is
>> assuming that the pointer was non-null, which was obviously incorrect, because
>> it was null. That's _not_ recoverable in the general case. Your code was
>> obviously written with the assumption that the pointer was non-null, so your
>> code is wrong, and so continuing to execute it makes no sense, because it's in
>> an invalid state and could do who-knows-what. If there's any possibility of a
>> pointer being null, the correct thing to do is to check it before
>> dereferencing it. If you don't, it's bug.
>> 
>> Now, it's perfectly possible to design code which never checks for null
>> pointers and if a null pointer is dereferenced throws an Exception and
>> attempts to recover from it (assuming that it's possible to detect the
>> dereference and throw at that point, which AFAIK is impossible with segfaults
>> - maybe it could be done on Windows with its Access Violations, but segfaults
>> trigger a signal handler, and you're screwed at that point). But writing code
>> which just assumes that pointers are non-null and will throw if they are null
>> is incredibly sloppy. It means that you're treating pointers like you'd treat
>> user input rather than as part of your code.
>> 
>> - Jonathan M Davis
> 
> All code has bugs in it. It's nice being notified about it and all, but if you release a server application, and it crashes every single time it encounters any bug... well, your customers will not have a fun time.

It's worth noting that Google apps abort on error. For server apps, a process crash is often designed to be invisible to the client, as much to allow seamless code upgrades as anything. 


More information about the Digitalmars-d mailing list