Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-12-16 18:51:27

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.

> 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.

If you don't like this example, it's easy to conjure up other ones.  One 
user might want to invoke save and invoke a stack trace while another 
doesn't want to do this for dependencies or other reasons.  The real 
point is that from where we work here, we can't know what the library 
user wants/needs.  It's better to factor this out and leave it to him.

Robert Ramey

>
> Emil
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>