Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-12-17 02:24:28

On 12/17/16 02:53, Robert Ramey wrote:
> On 12/16/16 2:05 PM, Andrey Semashev wrote:
>> On Sat, Dec 17, 2016 at 12:54 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>>> On 12/16/16 12:48 PM, Emil Dotchevski wrote:
>>>> a function will either succeed or it will not return.
>>> not necessarily
>>> bool f() {
>>> if ...
>>> invoke_error
>>> return failure or ignore error
>>> ...
>>> return success
>>> }
>>> if invoke error is mapped to throw exception then it will never
>>> return. If
>>> it's mapped to something else - like emitting an error message or
>>> invoking a
>>> user specified call back then it won't throw an exception.
>> That results in a really horrible API with dual error reporting
>> mechanisms.
> FYI - it's not a dual reporting mechanism. It's leaving the choice of
> reporting/handling mechanism to the library user. Once he selects it,
> that one is it.

It is a dual reporting mechanism from the standpoint of interface
definition. If the function uses exceptions to report errors, I expect
it to _not_ use error codes and such. In particular, the return value
can be used to return generated data or void. I do not have to examine
the returned error code. If the function uses error codes, I expect it
to not throw. I can use that function in noexcept contexts and do not
have to wrap it in try/catch.

If the function definition enables both reporting mechanisms, I have to
assume the error can be communicating both ways. Saying it will
communicate error one way and not the other in the docs is not
sufficient because it leaves room for error (both on the user's side and
the function developer's side). The policy has to be expressed on the
language level, by the function interface definition, leaving no room
for interpretation.

Boost list run by bdawes at, gregod at, cpdaniel at, john at