On 26/08/2015 02:02, Niall Douglas wrote:
On 25 Aug 2015 at 20:22, Gavin Lambert wrote:
Out of curiosity, in the Hello World example, is there any benefit of using when_all_p on all individual futures instead of merely waiting for the "read" future alone?
Since all the previous futures are cascaded to "read", any errors raised by earlier ops should be cascaded to the later ops anyway, so "read" should succeed only if all prior ops succeed (and presumably not even be attempted if prior ops failed). Or are you doing something different with errors? [...] What happens is that an errored input future is treated as if a default constructed input future. So, for this sequence: [...] 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.) 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).