On 29 Jun 2015 at 20:08, Gavin Lambert wrote:
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 already have a monad_category and a monad_errc which can do this.
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.
It's definitely a very valid concern. I'll sleep on it and make a decision. Thanks for commenting on this problem, it's a particular worry of mine. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/