C++ and system exceptions

cexception handling

Why standard C++ doesn't respect system (foreign or hardware) exceptions?

E.g. when null pointer dereference occurs, stack isn't unwound, destructors aren't called, and RAII doesn't work.

The common advice is "to use system API". But on certain systems, specifically Win32, this doesn't work. To enable stack unwinding for this C++ code

// class Foo;
// void bar(const Foo&);
bar(Foo(1, 2));

one should generate something like this C code

Foo tempFoo;
Foo_ctor(&tempFoo);
__try {
    bar(&tempFoo);
}
__finally {
    Foo_dtor(&tempFoo);
}
Foo_dtor(&tempFoo);

and it's impossible to implement this as C++ library.

Upd:
Standard doesn't forbid handling system exceptions. But it seems that popular compilers like g++ doesn't respect system exceptions on any platforms just because standard doesn't require this.

The only thing that I want – is to use RAII to make code readable and program reliable. I don't want to put hand-crafted try\finally around every call to unknown code. For example in this reusable code, AbstractA::foo is such unknown code:

void func(AbstractA* a, AbstractB* b) {
    TempFile file;
    a->foo(b, file);
}

Maybe one will pass to func such implementation of AbstractA, which every Friday will not check if b is NULL, so access violation will happen, application will terminate and temporary file will not be deleted. How many months uses will suffer because of this issue, until either author of func or author of AbstractA will do something with it?

Related: Is `catch(…) { throw; }` a bad practice?

Best Answer

The C++ standard doesn't respect system exceptions because it was designed to be usable on a wide range of platforms (much wider that PC-based platforms). It would be impossible to provide some sort of support for each of the platform in the standard. This is left for implementations and rightfully so.

My reaction to the rant part of your question: Win32 exceptions are thrown in fatal cases from which you can't really recover. __try & friends does work in C++ as well (not only for C), and you can manually call the destructor if you need to (but your program is in a state where it won't run anymore, so unless that destructor releases something the OS wouldn't normally release after the process terminated, there isn't much point).

Edit: In answer to your update: You are still ranting. It's not how you imagined it, so what? You can still protect yourself against the scenario you cited as an example. You use the platform-specific code to catch the system exception, close the file and crash gracefully. There might be a better way to do this; ask a specific question on SO. Isolating 3rd party code is not trivial and likely requires some effort to achieve (a good example of this is the famously unstable flash plugin which now runs isolated in most major browsers).

g++ doesn't respect system exceptions on any platforms just because standard doesn't require this

Even though it does implement a good number of extensions, gcc targets architectures, not platforms. Gcc itself is ported to different platforms but that's a different story; the code-generation part is architecture-dependent, not platform-dependent. This explains why it wouldn't be possible to support windows system exceptions without great effort.

Related Topic