Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-02-11 20:27:20

On Thu, Feb 11, 2016 at 4:57 PM, Gavin Lambert <gavinl_at_[hidden]>
wrote:

> 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