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/