Subject: Re: [boost] [Stacktrace] review
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-12-16 11:46:32
On 12/16/16 1:20 AM, Andrey Semashev wrote:
>> I think this should be compile-time hook in order to avoid the perils of
>> dynamic initialization in complex multi-thread programs. But we already
>> have that compile-time hook, it's called boost::throw_exception.
> The run-time hook can be tricky to implement, that is true, but in the
> simplest form it should be doable. The implementation details are of
> course discussable, but below is something more concrete to get things
> Introduce a process-wide singleton pointer,
This illustrates what the issue is and where we need to be moving.
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.
For example, the boost serialization library uses the traditional method
of defining exceptions and calling boost::throw_exception. But this
doesn't let users control behavior. My more recent effort -
safe_numerics, (in the boost library incubator) specifies a template
parameter which refers to an error policy and includes several options -
invoke exception, invoke specified function, etc... Something along
these lines is what I'm now thinking is where we should be headed. When
I did it for safe_numerics, I wasn't thinking of any general solution or
approach to usage of exceptions inside of library code, it's just came
naturally from the fact that pretty much the whole safe_numerics is to
deal with errors with a library.
To summarize, what is need is to come up with a "best practices"
recommendation to library authors as to how to deal with exceptional
conditions detected from withing a library.
Were this to occur and be convincing to library authors, the whole
question of what boost::throw_exception should do wouldn't have to be
agreed upon as it would be in the hands of the library user to decide.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk