Exception/Error division in D

Jonathan M Davis jmdavisProg at gmx.com
Wed May 30 15:21:48 PDT 2012


On Thursday, May 31, 2012 00:01:16 deadalnix wrote:
> Le 30/05/2012 17:29, Don Clugston a écrit :
> > There's a big difference. A segfault is a machine error. The integrity
> > of the machine model has been violated, and the machine is in an
> > out-of-control state. In particular, the stack may be corrupted, so
> > stack unwinding may not be successful.
> > 
> > But, in an assert error, the machine is completely intact; the error is
> > at a higher level, which does not interfere with stack unwinding.
> > 
> > Damage is possible only if you've written your destructors/finally code
> > extremely poorly. Note that, unlike C++, it's OK to throw a new Error or
> > Exception from inside a destructor.
> > But with (say) a stack overflow, you don't necessarily know what code is
> > being executed. It could do anything.
> 
> 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


More information about the Digitalmars-d mailing list