Boost logo

Boost :

Subject: Re: [boost] [next gen futures] Lightweight monad ready for inspection
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-06-29 04:08:17


On 21/06/2015 01:08, Niall Douglas wrote:
> Actually, I just lied. The monad get_or(), get_error_or(),
> get_exception_or() functions never throw no_state, they return the OR
> value. I am unsure if that is a wise design choice.

I think it is.

> There is also another potential design problem in that get_error()
> returns a null error_code if the monad is not errored even if it is
> excepted. I did it that way to match get_exception() as
> boost::future<T>::get_exception_ptr() returns a null exception_ptr if
> there is no exception. However there is a discrepency, because if the
> monad is errored not excepted and you call get_exception(), you'll
> get an exception_ptr to the system_error for the error_code, and it's
> not the same the other way round.

Perhaps there should be an error code that represents "has an
exception"? (Either from a custom category or finding an appropriate
system error to hijack for this purpose.)

I don't like the idea of someone writing code that only tests the
error_code (because they weren't expecting exceptions), but which claims
there is no error because there really was an exception instead.
Exceptions are errors are exceptions, and neither is an ordinary result
value.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk