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.