Re: [boost] Operating System API Error Reporting Guidelines

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-02-21 09:05:40

Peter Dimov wrote:

> 1. system_error 'obviously' needs to derive from std::exception, but whether 
> it needs to derive from std::runtime_error isn't clear.

Hum... I assumed that a system_error was 'obviously' a runtime error, 
and thus should be derived from std::runtime_error. What am I missing?

> 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.

Yep. Fixed.

> 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.

Yes, that is a better packaging. See below.

> 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.

namespace boost
{
   typedef int errno_type;
   enum errno_tag { errno_value };

   typedef implementation-defined system_error_code_type;

   class system_error : public std::runtime_error
   {
   public:
     system_error( std::string & what_arg, system_error_code_type ec );
     system_error( std::string & what_arg,
                   errno_tag tag, errno_type en );
     system_error( std::string & what_arg,
                   system_error_code_type ec, errno_type en );

     system_error_code_type system_error_code() const;
     errno_type errno_code() const;
   };
}

With the first constructor, errno_code() is looked up from ec.
With the second constructor, system_error_code() is looked up from en.
With the third constructor, both are explicitly given.

> (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.)

Use the third constructor if tight control over the mapping is needed.

> 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.

Good point. Fixed.

> HTH :-)

Yes, very much so. Thanks!

--Beman