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
