On 12/16/16 2:53 PM, Emil Dotchevski wrote:
On Fri, Dec 16, 2016 at 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.
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.
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. If you don't like this example, it's easy to conjure up other ones. One user might want to invoke save and invoke a stack trace while another doesn't want to do this for dependencies or other reasons. The real point is that from where we work here, we can't know what the library user wants/needs. It's better to factor this out and leave it to him. Robert Ramey
Emil
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost