Re: [boost] [afio] Formal review of Boost.AFIO

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 
https://github.com/BoostGSoC13/boost.afio/issues/98

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

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/