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

17 Dec 2016

      On Fri, Dec 16, 2016 at 3:51 PM, Robert Ramey  wrote:
...
On 12/16/16 2:53 PM, Emil Dotchevski wrote:
...
On Fri, Dec 16, 2016 at 2:05 PM, Andrey Semashev <
andrey.semashev@gmail.com>
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.
That's a matter of opinion.  It's just an example.  There are other ones
cited above which are better - but they're part of something a lot more
larger and not suitable for pasting here.
The real point is that we can't say apriori that that
boost::throw_exception should do a certain thing and no other thing.
What we can say is that no matter what else it does, boost::throw_exception
will not return, because that would be a breaking change. It should also be
obvious that if I want to throw an exception, the function I call may not
return.
...
Indeed. Again, enforcing postconditions is the main benefit of throwing.
...
Specifically:
if( condition-that-code-below-cant-deal-with )
  boost::throw_exception(my_error());
//safe to assume no error occurred because boost::throw_exception does nor
return.
The call to throw_exception is not merely reporting the error but also
protecting the scope that follows.
There are cases when that's not the only choice.  A floating point
calculation could result in a NaN.  In some cases one might want to pass it
on and other cases one might want to trap it as an exception.
You maybe confusing the terms. There are system exceptions, which you seem
to be referring to ("trapping" is part of the terminology used in the
floating point IEEE standard), also known as asynchronous exceptions
because they may occur at any instruction. This has nothing whatsoever to
do with the exception handling mechanism defined by the C++ standard.

I am not saying that it is impossible to let the user decide if library
functions throw or use some other error reporting mechanism, only that if
the user is given that choice, it makes C++ exceptions useless to the
library developer, because he must always define behavior for the error
branch, like a C programmer must. This is error-prone and can be costly,
both in terms of development effort and run-time overhead.

Emil