Beman Dawes wrote:
Fresh draft up at www.esva.net/~beman/error_reporting_guidelines.html.
This tries to incorporate concerns, comments, and suggestions from Eric Niebler, Dave Abrahams, and John Maddock.
Further comments welcome,
1. system_error 'obviously' needs to derive from std::exception, but whether it needs to derive from std::runtime_error isn't clear. 2. A constructor is provided for users to be able to construct a system_error, but this constructor requires a string and doesn't require a system error code. This is backwards; it is precisely the system error code that makes a system_error distinct from a mere runtime_error. Take it away, and it's not a system_error anymore. A system_error should be constructible from a system error code, with the library supplying an appropriate what() string. 3. lookup_errno assumes that there is a context-free mapping from system error codes to errno. The alternative approach of class system_error { public: int errno() const; system_error_code_type system_error_code() const; }; does not. 4. The proposed mechanism does not allow me to signal failure when all I have is an errno value, since I have no way of translating that back to a system error code. (Even if I did have such a way, it might not be desirable to use it because the roundtrip translation may or may not result in the original errno.) 5. Some system_errors can (and in some cases, ought to) be mapped to existing exceptions, the most prominent example being ENOMEM, which should be reported as std::bad_alloc. HTH :-)