On Thu, Feb 11, 2016 at 4:57 PM, Gavin Lambert
On 12/02/2016 12:56, Emil Dotchevski wrote:
Perhaps I'm biased by mostly developing on Windows+MSVC, but since that
implements C++ exceptions by raising OS exceptions, and OS exceptions can be caught and processed just like C++ exceptions, I don't see any distinction between the two. (Though I'm aware that the OS exception handling mechanism is much more broken on non-Windows.)
It's criminal that MSVC can translate OS exceptions into C++ exceptions. :) It's not that it's broken on other OSes, other compilers don't do this because it's wrong. I do not recommend turning that MSVC option on.
It's not an option. That's just what it does.
Not true, it's an option. They call it "structural exception handling".
There are some good things about this, as it makes it easier to recover a stack trace from a thrown exception -- though the corollary bad thing is that exceptions are also more expensive to throw.
You can love it or hate it, but as a matter of fact it's not standard behavior, and I am not aware of any compiler other than MSVC that implements it. Basically, long time ago someone at Microsoft read the word "exception" and interpreted the standard incorrectly, and now they can't remove this broken behavior for legacy reasons.
Absolutely not. Dereferencing a null pointer in C++ is undefined behavior,
which is not at all the same as throwing exceptions or raising OS exceptions. When you throw an exception, the standard specifies exactly what is going to happen, but in the case of undefined behavior all bets are off. Maybe your program will crash, maybe it'll send a nasty email to your boss. :)
On pretty much any platform with an MPU the memory around address 0 is left unmapped precisely such that such accesses generate an OS fault.
Yes, but there is no requirement for the program to be able to unwind the stack and call destructors, as it does when throwing C++ exceptions. It's makes no sense to expect a program to be able to recover from undefined behavior because at that point the state of the program is undefined, by definition.
You're taking this out of context, though; it was an aside only peripherally related to the main point.
If we're talking about the problems of C++ exception handling and when it is and it isn't appropriate to use it, it's important to be on the same page about what exception handling is. And it most definitely is NOT the "structural exception handling" behavior in MSVC. That should never be used, except if you're dealing with an old code base that relies on it. Emil