Boost logo

Boost :

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-27 20:36:05

On 27 Aug 2015 at 17:27, Gavin Lambert wrote:

> > In this sense, you're right that an error will *probably* cascade
> > into dependent operations. But AFIO is deliberately stupid, and lets
> > the OS decide what is valid input and what is not, and it returns
> > back whatever the OS tells it.
> Just to rehash this point a little -- in the "Exception Model" section
> on pretty much all the functions it explicitly states that it propagates
> the exception of input preconditions.
> To me, this implies that the same should apply to error codes -- if the
> input precondition has an error code, then the function should output
> the *same* error code without attempting to perform the operation (and
> in particular not losing the original error code and replacing it with a
> "handle not valid" error code, which would almost certainly be the
> result of actually calling the OS function).
> I know that error codes and exceptions are technically different, but
> other than having different performance characteristics I think that
> they should be treated logically the same. (I think I've mentioned this
> before.)

You've found a documentation bug. Of course error_code and exceptions
are treated both as errors which are propagated. Logged at

> Where this might fall down of course is that if you're just blindly
> exposing OS error codes, you might have codes that aren't actually
> errors, like "no more items" following an enumeration operation. Other
> than handling and concealing that internally (which might not be
> feasible depending on the API) I'm not sure of a good solution to this,
> unless there's a generic way to tell whether a given code is a "success"
> or a real failure (which is somewhat possible on Windows for HRESULT- or
> NTSTATUS-based APIs but not on POSIX or basic Win32 APIs, AFAIK).

The wider question of whether AFIO should treat errored input futures
as if they are null handles or not is an interesting one. I chose it
mainly because of simplicity - same dispatch and handling code for
all operations, whereas any special treatment would not apply to any
function which opens a file handle as opening a new file handle is
entirely a valid response to an error. I also didn't want to get in
the way of any third party created custom handles which might do
something different.

But maybe instead of generating a new error with a new backtrace for
every single failed operation one instead propagated a copy of the
original failure, that might help with debugging?


ned Productions Limited Consulting

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