If really the author meant to add noexcept, she must then be aware of the problem and properly handle exceptions anyway, as IIUC all this is merely a runtime check that leads to program abortion.

Its sadly easy to allow exceptions, they are slippery little things:

int f() try {
    the code;
} catch(...){
    now I must not allow anything to throw here;
    careful of IO, constructing objects, operators;
    sheesh, not much you CAN do;
    better just terminate, or return -1;
}

The nice thing about the noexcept is it can catch exceptions from the catch clause too, so it would be good if it could be used.

So authors of C++ plugins are forced to consider the issue. But that breaks C++ API.

Though I wouldn't expect too many C++ plugins for the new API, yet, now is the best chance.

Though, I still wonder how this can change the ABI, especially in C linkage where there can't be no name mangling anyway.

I wouldn't think it would change the ABI, I would have expected the stack frame to have a flag saying this function is noexcept so the unwinder can see it and terminate. So its internal to the function. But it is implementation dependent, so who knows.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.