Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at