Re: [boost] [Boost] [Stacktrace] review

17 Dec 2016

      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  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.