Exception/Error division in D

[deadalnix]

Le 31/05/2012 00:21, Jonathan M Davis a écrit :
> 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.
>

I want to remind you that the subject is knowing if scope and finally 
block should be triggered by errors.

Such blocks are perfectly safe to execute in such a situation.

Additionally, I may want to abort the current operation, but not the 
whole program. This is doable on such an error.

> 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).

Well, I have a pull request in druntime that do exactly what you claim 
is impossible.