Do other Boosters like the idea of an overall guideline for dealing with operating system API error reporting?
Yes.
Unless otherwise specified, the default versions of all Boost library functions, except destructors, that call operating system API functions should check for API errors and report the occurrence of such errors by throwing an exception of type boost::system_error.
OK, but what about "critical" errors: OS API failures that mean the library can't function at all, or even place it's object in a consistent state? Sometimes a for truely *exceptional* conditions a throw (or abort if no exceptions are available) makes more sense. I guess the problem is that the filesystem lib necessarily generates errors rather often, compare to most other libs, so the error conditions aren't "exceptional" in the traditional sense.
Such functions should also have an overload that takes an additional argument of type boost::system_error_code& ec. The behavior of this overload is the same as the non-overloaded version, except that it does not throw an exception on an API error, and it sets ec to the error code reported by the operating system, or to 0 if no error is reported.
Hmm, not so sure about this: certainly as far as regex is concerned, most OS API calls are critical for correct functioning of the library, but they're also very *very* rare to fail, and platform dependent whether OS API's are even called at all. What about other exceptional conditions that may arise: std lib errors, math errors etc? Should these have optional error code reporting as well? If so do we apply this to every API in Boost? I don't have any good answers to these questions, but I'd like to :-) BTW the rest of the paper sums up the issues very nicely, but I don't think we have the right resolution quite yet, or at least we should think very carefully before we leap in :-) John.