Re: [boost] [Boost] [Stacktrace] review

On 12/16/16 12:48 PM, Emil Dotchevski wrote:

On Fri, Dec 16, 2016 at 8:46 AM, Robert Ramey 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