Re: Diagnostic improvements in 1.78/1.79

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2022-02-15 02:54:00

On Mon, Feb 14, 2022 at 6:38 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:
>
> Gavin Lambert wrote:
> > On 15/02/2022 14:53, Peter Dimov wrote:
> > > I think I like Emil's user-provided handler better, because with it
> > > the user would control whether and what is collected.
> >
> > I did consider mentioning that, but what I don't like about that option
is that it
> > leaves things a bit too vague.
> >
> > (And in terms of ThrowException itself, it's fundamentally equivalent
to the
> > NO_EXCEPTIONS path, by making it call a user-provided method to do the
> > actual work.  Which then seems to defeat the point of having it be a
library at
> > all.)
> >
> > It puts the burden entirely on the end-user to select the mechanism for
error
> > info propagation, and library authors would have a harder time
interfacing
> > with it.
>
> I think there might be a misunderstanding here. What I envisage is this
>
> void (*throw_handler)( std::exception const& ex, boost::exception& bx,
>   boost::source_location const* loc ) = default_throw_handler;
>
> void set_throw_handler( auto* p ) { throw_handler = p; }
>
> void default_throw_handler( std::exception const& ex, boost::exception&
bx,
>   boost::source_location const* loc )
> {
>     if( loc ) bx.set_location( *loc );
> }
>
> template<class E> BOOST_NORETURN void throw_exception( E const & e )
> {
>     wrapexcept<E> wx( e );
>     throw_handler( e, e, 0 );
>     throw wx;
> }
>
> template<class E> BOOST_NORETURN void throw_exception( E const & e,
>   boost::source_location const & loc )
> {
>     wrapexcept<E> wx( e );
>     throw_handler( e, e, &loc );
>     throw wx;
> }
>
> That is, boost::throw_exception still adds a boost::exception base, and
that's
> the mechanism for error info propagation; the user just gets to put things
> into it before it's thrown - such as a stack trace.

Thank you for spelling it out. Maybe take the boost::exception object as a
pointer though? That way this (standard for Boost in the future) handler
can be invoked with exception objects that do not derive from
boost::exception (even though boost::throw_exception guarantees that they
do).