Re: [boost] [Stacktrace] review

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

On 12/16/16 12:48 PM, Emil Dotchevski wrote:
> On Fri, Dec 16, 2016 at 8:46 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>
>> For many C++ programs and libraries, the exception is a convenient way to
>> handle errors and for this reason is widely used.  Traditionally, library
>> authors have documented exceptions that they threw and let user programs
>> decide to catch and handle them.  To deal with platforms which didn't
>> provide exceptions we threw through boost::throw_exception.  So far so
>> good.  But as we make bigger and more complex programs using mulitple
>> libraries from different sources, this becomes somewhat of a problem to
>> keep track of.  And users would like to have systematic way of "unifying"
>> them.  So I'm thinking the real solution is to develop customs and idioms
>> for usage by library authors which would permit users to specify the way
>> they would like to see exceptions handled.
>>
>
> This is missing the point of using exceptions. Beyond a mechanism for
> reporting errors, exceptions enforce postconditions:

failing a post condition would be an error

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

Specifically, note that even under
> BOOST_NO_EXCEPTIONS, boost::throw_exception is NOT allowed to return, or
> else it would be useless to library developers
Right - it's already useless to library developers

 > (because they couldn't use it to enforce postconditions.)

 > There might be exceptions to this, but whether a function throws
 > or not should not be configurable by the user.

In general, a library writer is not the best person to decide how to 
handle various exception conditions.  In many simple cases it doesn't 
matter.  In others it's obvious that there is no way to make one size 
fits all.  Refer to previously noted examples

Reflecting on this, I think that this difference of point of view is 
source of our difference of opinion.  I don't believe that I can really 
anticipate what the use is going to want to do when a exception 
condition occurs.  This leads to trying to guess.  Which in turn 
requires the user to work his own code library or application to 
accommodate his code to the decision I, as a library writer, I've made 
on his behalf.

Robert Ramey