Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-14 23:53:57

On 15/05/2017 11:33, Niall Douglas via Boost wrote:
>> In particular, if you're going to explicitly add a constructor to
>> MathError2 such that it knows how to construct itself from MathError1
>> (as in the final example), why would you not put the switch statement
>> from the first example into that constructor, such that it actually
>> translates the error codes into the expected domain?  Especially when
>> there is no loss or overlap in doing so, as in these examples?
>
> If you're writing a switch statement or doing any form of mapping with
> error codes, you're doing it wrong from C++ 11 onwards.
>
> One always wants to preserve and propagate exactly the original error
> code, unmodified in any way. That's the whole point of <system_error>.

If you have a class which could have any of a large number of possible 
implementations (perhaps platform-specific), and as a consumer of that 
class you don't care which, why would you want it to expose a 
file_not_found error or a database_key_missing error when as far as 
you're concerned they're just a key_not_in_dictionary.

Don't take that example too literally -- the point is that if the 
internal implementation is hidden, exposing internal errors seems 
somewhat meaningless to consumer code.  And brittle -- maybe the 
application code was written to handle the file_not_found case but then 
the library was changed to use a database backend and started raising 
database_key_missing errors instead, and now suddenly all the error 
handling is wrong.

Granted the below possibly provides some insulation from that, but it 
still requires someone to define a POSIX equivalence, and I'm sure there 
would be cases where the same internal error code logically means 
different things at the surface API, so such equivalence would be 
misleading.

> <system_error> lets code with no knowledge of some custom error code
> domain work with that error code domain, and without recompilation. It's
> very clever. Both Outcome and Expected are intended to make using
> error_code much easier and safer for end users than it has been until now.

Only where someone provides a mapping to standard POSIX errors, or just 
wants to log errors without logic.