Re: [boost] Operating System API Error Reporting Guidelines

21 Feb 2006

      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

Re: [boost] Operating System API Error Reporting Guidelines

Beman Dawes