Subject: Re: [boost] Boost.Outcome review - First questions
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2017-05-25 00:13:08
Thanks for attempting to additionally clarify what you said before.
> Again, sorry to reply on behalf of Niall, but it is my description that
> might have caused the confusion.
I'm glad you try to answer my questions as I know I will not get any from Niall directly.
> There is still this case where you want to avoid exceptions in one part of
> the program, but still use exceptions in other parts of the program. For
> one example. in one "task" you launch another task with a callback
> function `f`. You might want to throw from `f` and this is valid. But the
> framework for launching tasks cannot afford to spill exceptions, so they
> have to catch and somehow transport the exception (e.g., by exception_ptr)
> then in the other task, you might want to re-convert to an exception.
> (something similar to what std::future does.)
I understand what you're saying, std::future needs a (conceptual) variant<T, exception_ptr> to store its state. So if I hear you correctly, outcome::expected<T, exception_ptr> could be used for that.
> Other situation, is when you are using a third-party library, which throws
> exceptions. You want to wrap it into a component that does not throw.
> Boost.Outcome also supports in a convenient way this transition from and
> to exceptions.
> Also, maybe you will find of use the following example that tries to
> illustrate the basic use case of the library:
<snipped code example>
Thanks, I think I've seen this in the docs. All of this could have been done with a variant<T, some_error_type> without changing the semantics, yes?
So I guess the next question I would like to ask is: what is the benefit of using outcome::result<T> over std::optional<T>, and outcome::expected<T, E> over std::variant<T, E>?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk