Re: Diagnostic improvements in 1.78/1.79

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2022-02-15 01:19:11

On Mon, Feb 14, 2022 at 4:50 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> It's nice to have stack traces, but we can't realistically make
> ThrowException
> depend on Stacktrace, for several reasons. First and least, dependency
> cycles.
> Second, Stacktrace is not header-only, so all header-only libraries that
> throw
> exceptions will acquire a compiled dependency, which is a massive pain.
>
> And third, even for compiled libraries, the way Stacktrace uses separate
> library
> per backend makes it hard to express the dependency in b2 or CMake, because
> you have no idea what target your library needs to link to.
>
> All in all, that's currently impractical (for Boost libraries.)
>

It is not practical to make all code that deals with Boost exceptions
depend on Stacktrace, but is it practical to provide an interface for the
user to attach a stack trace, e.g. a callback that takes a boost::exception
by reference, and we pass the exception object to it before we throw it?

> But there's more to it. If you follow a straightforward style in which you
> immediately throw on error, capturing stack traces on throw works well. But
> if your library is written to use error codes internally, so that it can
> expose a
> dual API to the user, that is, to be usable with either exceptions or
> error codes,
> things are not so rosy. That's because failures are propagated upwards
> through
> several layers using error codes, and only at the last layer is that
> turned into
> an exception. So you get a stack trace from that point upwards, which is
> not
> as helpful.
>

Boost LEAF fixes this. :)

In principle it is not correct to focus on any particular error info,
because what error info is needed is project-specific and/or user-specific.
It also doesn't make sense in terms of coupling, not to mention (as you
pointed out) it could lead to circular dependencies.

Ideally, we provide the capability for obtaining different kinds of error
info, e.g. a stack trace, and the capability to transport it when errors
are propagated, and leave it to the user to stitch things up together.