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: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-15 08:20:22

2017-05-15 0:54 GMT+02:00 Gavin Lambert via Boost <boost_at_[hidden]>:

> On 12/05/2017 04:19, charleyb123 wrote:
>
>> The formal review of Niall Douglas' Outcome library starts next week
>> (Fri-19-May to Sun-28-May).
>>
> [...]
>
>> - What is your evaluation of the documentation?
>>
>
> Granted std::error_code does let you transport "foreign" error codes, but
> surely translating recognised codes from a method's internal implementation
> to those of its external interface is desirable?  (Though perhaps that may
> depend somewhat on your views of encapsulation and implementation hiding.)

I think, breaking encapsulation in case of reporting failures from
functions (be it an exception or an error code) is generally expected and
desired, even though nobody will say it explicitly.

When I want to communicate with another subsystem, I want the mechanisms of
the communications to be abstracted away from me. But when it gets wrong, I
want all the information: that I was in fact using the TCP/IP for
communication; even exposed to the users, because they may know how to
respond.

Regards,
&rzej;