Re: [boost] Operating System API Error Reporting Guidelines

From: John Maddock (john_at_[hidden])
Date: 2006-02-18 05:57:36

>> Do other Boosters like the idea of an overall guideline for dealing
>> with operating system API error reporting?

Yes.

>>   Unless  otherwise specified, the default versions of all Boost
>>   library functions, except destructors, that call operating system
>>   API functions should check for API errors and report the
>>   occurrence of such errors by throwing an exception of type
>> boost::system_error.

OK, but what about "critical" errors: OS API failures that mean the library 
can't function at all, or even place it's object in a consistent state? 
Sometimes a for truely *exceptional* conditions a throw (or abort if no 
exceptions are available) makes more sense.

I guess the problem is that the filesystem lib necessarily generates errors 
rather often, compare to most other libs, so the error conditions aren't 
"exceptional" in the traditional sense.

>>   Such  functions  should also have an overload that takes an
>>   additional argument of type boost::system_error_code& ec. The
>>   behavior of this overload is the same as the non-overloaded
>>   version, except that it does not throw an exception on an API
>>   error, and it sets ec to the error code reported by the operating
>> system, or to 0 if no error is reported.

Hmm, not so sure about this: certainly as far as regex is concerned, most OS 
API calls are critical for correct functioning of the library, but they're 
also very *very* rare to fail, and platform dependent whether OS API's are 
even called at all.

What about other exceptional conditions that may arise: std lib errors, math 
errors etc?  Should these have optional error code reporting as well?  If so 
do we apply this to every API in Boost?

I don't have any good answers to these questions, but I'd like to :-)

BTW the rest of the paper sums up the issues very nicely, but I don't think 
we have the right resolution quite yet, or at least we should think very 
carefully before we leap in :-)

John.