Boost logo

Boost :

Subject: Re: [boost] expected/result/etc
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-02-09 18:41:48

On 10/02/2016 09:04, Emil Dotchevski wrote:
> The use of error codes in low level APIs is a fact of life, since most of
> that code is written in C anyway. I wouldn't call it optimal in C++, I
> personally convert error codes into exceptions at the earliest possible
> opportunity. As for runtime overhead, like I said already, where it matters
> it can be easily deleted, by inlining; and, in such contexts you need to
> inline with or without exception handling: I've never seen a case where I
> could afford the overhead of a function call but could not afford the
> exception handling overhead in the same function.

The overhead of exception-handling plumbing that is not actually
exercised is typically minimal and not worth worrying about unless
you're in one of those contexts where you begrudge every method call, as
you've said.

The overhead of a thrown exception is larger, particularly on those
systems where throwing an exception also captures a stack trace (which
is incredibly helpful for debugging, but sadly often quite expensive).

The overhead of dealing with error return codes for uncommon failures is
also fairly large, with the risk of ignoring them and ending up in weird

The trick is to find the balance between them, with the complication
that it may not be known at the library level which failures are
exceptional and which are expected. As an example, I can imagine that
most applications don't want a "delete file" method to throw an
exception if the file is already absent -- but there might be some
transactional systems in which that would be a serious problem, and
checking for existence beforehand might not be sufficient as it would
still be a race condition.

This sort of thing could be a good argument for "degrees of success",
where eg. the above delete call returns success in both cases but can
also indicate that the file was already missing and it did nothing.
(Which is trivial in this case since it can be done with a simple bool
return value, but you can probably imagine other cases where it might
make sense to return both a T and a non-error status value of some kind.)

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