Re: [boost] Operating System API Error Reporting Guidelines

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-02-19 10:59:59

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 :-)