How D intercepts runtime errors

[Jarrett Billingsley]

"Serg Kovrov" <user at domain.invalid> wrote in message 
news:eaagfg$1k5d$1 at digitaldaemon.com...

> I'm more or less understand what happen in C/C++ when incorrect pointer
> being dereferenced. But could someone kindly explain to me how it works
> in D, please?
>
> I mean, who (and how) is checking pointer I try to use, who throws
> exception, etc.. I is it garbage collector routine injected into my
> executable, or some other part of standard library, or maybe something
> completely different...

D, as well as most modern C++ implementations, use the underlying OS's 
exception handling mechanisms; on Windows, it's Structured Exception 
Handling (SEH), and on *nix, it's usually signals.  I'm just going to 
discuss SEH, as I don't know much about *nix signals, but I'd assume they 
are fairly similar.

What happens is that the application registers an exception handler with the 
SEH system.  When a system exception occurs (such as a memory access 
violation, which is, by the way, detected by the processor and memory 
controller - it's in the hardware), the OS calls the exception handler, 
giving it a chance to convert the system exception into a software exception 
which the program can understand.  You can see this in 
/dmd/src/phobos/internal/deh.c, in the _d_translate_se_to_d_exception 
function: notice the "cast STATUS_ACCESS_VIOLATION" clause.

> And of course, how it could affect performance.

All exception handling methods incur some performance penalty, but since 
access violations are implemented in the PC hardware, there is no 
performance penalty that you can't circumvent.

> Ah, there is some more. Is there something D could not intercept? I mean
> is there a way to crash/segfault program? Kinda silly question, yes. But
> knowing that could help to avoid it.

Perhaps if there is an exception thrown before the exception handler routine 
is registered?  Another possibility is if an exception is thrown outside the 
_Dmain's try block (see /dmd/src/phobos/internal/dmain2.d).  Maybe an out of 
memory exception or something.