Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-12-16 13:20:58

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey
> Sent: 16 December 2016 16:47
> To: boost_at_[hidden]
> Subject: Re: [boost] [Boost] [Stacktrace] review
> 
> 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
> > started.
> >
> > Introduce a process-wide singleton pointer,
> 
> <snip>
> 
> 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.

John Maddock gave serious thought to this when devising the Policies concept for Boost.Math (after some mutterings from me).

This allows people to be all C-ish and ignore just bad input thru to throwing C++ exceptions, and control other things like accuracy
and precision too.

It seems to work well (except that many people need reminding that if you don't catch exceptions, you don't get any info about when
went wrong - it just ends with a muted phut :-).

Downside is that it makes the code harder to write and much more confusing to read.

This too might be a model for other libraries.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]