Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-12-16 19:32:12

On Fri, Dec 16, 2016 at 3:51 PM, Robert Ramey <ramey_at_[hidden]> wrote:

> On 12/16/16 2:53 PM, Emil Dotchevski wrote:
>
>> On Fri, Dec 16, 2016 at 2:05 PM, Andrey Semashev <
>> andrey.semashev_at_[hidden]>
>> wrote:
>>
>> On Sat, Dec 17, 2016 at 12:54 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>>>
>>>> On 12/16/16 12:48 PM, Emil Dotchevski wrote:
>>>>
>>>>>
>>>>> a function will either succeed or it will not return.
>>>>>
>>>>
>>>> not necessarily
>>>>
>>>> bool f() {
>>>>         if ...
>>>>                 invoke_error
>>>>                 return failure or ignore error
>>>>         ...
>>>>         return success
>>>> }
>>>>
>>>> if invoke error is mapped to throw exception then it will never return.
>>>>
>>> If
>>>
>>>> it's mapped to something else - like emitting an error message or
>>>>
>>> invoking a
>>>
>>>> user specified call back then it won't throw an exception.
>>>>
>>>
>>> That results in a really horrible API with dual error reporting
>>> mechanisms.
>>>
>>
> That's a matter of opinion.  It's just an example.  There are other ones
> cited above which are better - but they're part of something a lot more
> larger and not suitable for pasting here.
>
> The real point is that we can't say apriori that that
> boost::throw_exception should do a certain thing and no other thing.
>

What we can say is that no matter what else it does, boost::throw_exception
will not return, because that would be a breaking change. It should also be
obvious that if I want to throw an exception, the function I call may not
return.

> Indeed. Again, enforcing postconditions is the main benefit of throwing.
>> Specifically:
>>
>> if( condition-that-code-below-cant-deal-with )
>>   boost::throw_exception(my_error());
>> //safe to assume no error occurred because boost::throw_exception does nor
>> return.
>>
>> The call to throw_exception is not merely reporting the error but also
>> protecting the scope that follows.
>>
>
> There are cases when that's not the only choice.  A floating point
> calculation could result in a NaN.  In some cases one might want to pass it
> on and other cases one might want to trap it as an exception.
>

You maybe confusing the terms. There are system exceptions, which you seem
to be referring to ("trapping" is part of the terminology used in the
floating point IEEE standard), also known as asynchronous exceptions
because they may occur at any instruction. This has nothing whatsoever to
do with the exception handling mechanism defined by the C++ standard.

I am not saying that it is impossible to let the user decide if library
functions throw or use some other error reporting mechanism, only that if
the user is given that choice, it makes C++ exceptions useless to the
library developer, because he must always define behavior for the error
branch, like a C programmer must. This is error-prone and can be costly,
both in terms of development effort and run-time overhead.

Emil