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
> <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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk