Subject: Re: [boost] Boost.Outcome review - First questions
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2017-05-24 14:36:42
> > So, Emil's initial question is still unanswered (at least for me, and
> > please
> > feel free to just point me to an email thread or similar which already
> > succinctly answers this - I apologize if I missed that): what is the use
> > case for the outcome library?
> > Replacing exceptions for error handling? If yes, why?
> > Replacing the use of error codes for error handling? If yes, why not
> > exceptions?
> > I'd appreciate any possible clarification on this matter as I'm growing
> > more
> > and more confused by the ongoing discussions.
> Maybe I can answer this. The most general answer is that Boost.Outcome is
> for people who want to reasonably decently report and handle failures and
> at the same time choose, or are forced, not to use exceptions.
> The reasons for not using exceptions may be different:
> - Real or imaginary concerns about performance
> - A personal style of programming
> - Company's policy to compile with exceptions disabled
> - Maintaining a code base that was never designed with exception-safety
> in mind
> - Making all control paths explicit, as opposed to having hidden
> paths caused exceptions potentially thrown from any place
> - Parts of the programs/frameworks that themselves implement exception
> handling and cannot afford to use exceptions, like propagating failure
> reports across threads, tasks, fibers...
> Once you have decided not to use exceptions in some part of the program,
> Boost.Outcome offers convenient abstractions for you, likely superior to
> error codes. It implements 95% the currently being standardized
> `std::expected` library, plus a number of other useful additions.
Thanks Andrzej, that's very insightful, exactly what I was looking for.
May I suggest to use this paragraph as the motivating text for the library
in its docs? Something like this would have saved a lot of head scratching
(at least for me) to begin with.
Also, if this is really what the library is about, may I suggest to remove
all mentioning of exceptions from the library itself, its documentation, and
the related examples?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk