On Wed, Nov 20, 2019 at 2:50 AM Mathias Gaunard via Boost-users < boost-users@lists.boost.org> wrote:

On Mon, 18 Nov 2019 at 23:55, Nat Goodspeed via Boost-users wrote:

...

Since the arrival of Boost.Stacktrace, I've been expecting a

conventional boost::errinfo_stacktrace helper to join the suite of other boost::errinfo_mumble helpers. Is there a PR open with that?

There's already support for it.

https://www.boost.org/doc/libs/1_65_1/doc/html/stacktrace/getting_started.ht...

I never got the point of boost.exception though. If you want exception info, just hook into your exception runtime and get all of them, instead of just the ones thrown with the boost exception magic.

The point of Boost Exception is to augment exceptions in flight regardless of their exact type. At the point of the throw, you don't typically have all relevant information to put in the exception object, for example when reporting a file read error you don't have the file name available. Boost Exception allows you to add file names and anything else later on.

On 21/11/2019 09:58, Mathias Gaunard wrote:

In any case catching and rethrowing exceptions at every layer to add context information as it bubbles up is not really an idiom I would recommend. Not only is quite ugly and complexifies control flow, it's also inefficient and leads to a poor experience when debugging.

I think it works reasonably well, without too much ugliness. It's a bit better in the .NET languages, since they adopted the idea of nested exceptions from the start -- at each catch site, you can choose whether to add additional details to the existing exception and rethrow it (although this is rarely done since it typically isn't visible in the string output), to throw another exception with the original nested within (most common), or to throw another exception without the original (rarer, but occasionally appropriate). While C++ now has the ability to do nested exceptions as well, the plumbing required to actually deal with them (and to extract and log information) is still pretty terrible. And most existing code will neither nest exceptions nor unpack them. Granted, it can be a little annoying to debug if you have it set to break on all exceptions (rather than just uncaught ones), but even so, exceptions should be rare and following it up the call chain can be useful in itself, so it's not all that poor an experience. Usually the only time exceptions cause a poor debugging experience is when code is using them incorrectly (as control flow, not for exceptional cases; which often leads to try-catch-ignore anti-patterns).

It is a better idea to use normal control flow for this.

How would you use normal control flow for that example? (Failure to parse at a low level that doesn't know the filename, and the higher level does know the filename.)