`f` should not need to know what errors are being returned by `do_f1`, `do_f2`, `do_f3`, in order to check whether the calls succeeded; the whole point of using error_code is that errors from different domains can be handled in a generic manner.
No, this is just one approach to error handling, and defining the error handling approach is beyond error_code's scope. The responsibility of error_code is simply to encapsulate the error values that originate from different domains.
I think that *was* the case in the past, and by individuals such as yourself Chris in the code that you personally have written. But Peter's right: the typical use case patterns for error_code have evolved into something different, more complex, more generic. And that's a good thing, even if currently there is lots of subtly broken code out there right now.
There must exist a generic way to test for failure.
Why must this exist? (With the emphasis placed on "generic".)
So templated code which composites unknown code can be useful. Right now it must assume "if(ec)" means "if error" due to no generic alternative.
You can achieve this within certain domains and error handling designs, sure. However, testing for failure using only the error code is not possible for all use cases where error codes are applicable or, indeed, already used.
Currently, yes. But a retrofitted error_code ought to work nicely. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/