Re: [boost] Boost.Outcome review - First questions

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
> using
> > 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
> control
>    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?

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu