Re: [boost] [outcome] success-or-failure objects

Subject: Re: [boost] [outcome] success-or-failure objects
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2018-01-25 01:15:17

On Wed, Jan 24, 2018 at 3:34 PM, Gavin Lambert via Boost <
boost_at_[hidden]> wrote:

> On 24/01/2018 19:33, Emil Dotchevski wrote:

How can you guarantee this? In some other language, maybe. In C/C++, you
>> can't.
>>
>
> I cannot think of a case where it would be false that does not require
> some kind of memory corruption as a prerequisite.  Granted, memory
> corruption is vastly easier to achieve in C/C++ than in some other
> languages, but modern C++ is trying to discourage practices that lead to it.
>

What you're saying is that in many cases, undefined behavior may not crash
your program -- but this is not a good thing, because it might do something
worse than that. If you consider your web browser example, it might lead to
an attacker accessing the user's file system, all because you thought it's
safe to throw.

> If it is a logic error for the caller to not expect this state, you have no
>> idea what the caller will end up doing and you most definitely can't
>> expect
>> you can safely throw.
>>
>
> You can always safely throw.  Sometimes it will have poor consequences
> (eg. leaking memory, leaving bad data, abandoning locks, aborting the
> process), but those are all well-defined consequences and are themselves
> side effects of poor coding practices that can be corrected.
>

Not only it is not safe to throw after you've detected a logic error,
throwing can itself be a logic error. I honestly don't know where to take
the discussion from here, it seems like in your mind logic errors are the
same as any failure, which is simply not true.

Emil