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?