Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk