Re: [boost] Re: Next revision of boost::thread & OS error code.

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-10 10:07:07

> From: Martin Brown <martin_w_brown_at_[hidden]>
> 
> Hi,
> 
> Regarding the OS error code / exception type debate; I
> may have missed something here, so apologies if I
> have.   Speaking as a user of your wonderful
> libraries:
> 
> 1. I need all the data available - the error may be
> happening on a computer in Japan and the data may be
> filtered through many layers of sales and support.

All of what data?  Full stack traces and memory dumps for instance?  Do you think it's reasonable for a library to provide this much data, or is it the responsibility of the application?  What's the minimal amount of information that you think must be provided by the library?

> 2. The user needs a localised error message.

Is the textual representation of the exception name enough?  If not, how do you propose a library provide such a localised error message?
 
> 3. Most errors are for the user to deal with.   Many
> problems are simply due to configuration (e.g.
> permissions) or interaction with other software (e.g.
> virus scanners).   Auto-recovery is often only
> possible to a limited extent.
> 
> 4. Exception object types are useful for
> auto-recovery, but are less important when generating
> a message for a user.

Interesting view point.

> (1) implies that the error reporting system cannot
> destroy any information (e.g. representing many error
> codes in a single exception object with no way to get
> at the original code).

What I'm not convinced about here is the fact that error codes are system dependant.  More importantly, most of them can be accessed by calling a system specific function or other mechanism (errno and GetLastError are examples).  (OK, these mechanisms are a little fragile since the "last error" can be changed if intermediate exception handlers called methods which also set the errno... but such exception handlers *could* be made to not do this.)  So with out a "standard" mechanism for reporting error messages, I'm not sure that carrying a non-portable error code is truly beneficial.  And with a "standard" error reporting mechanism it may be that what() alone would meet all usage requirements.

I think finding a solution to this problem would be nice, but I'm not about to be the one to tackle it, and it would be a seperate library any way.  So I'm left with a lot of vague "wishes" that I can't meet alone, and no concrete consensus of what a "minimal" solution should be.

> (2) & (3) imply that OS error codes must be available
> for generating a message using the OS facilities.   It
> is pointless having a boost set of error codes, as
> this would require boost writing and maintaining
> localised error messages.   

But there will be non-OS errors that have to be reported as well.  How do you intend to deal with both types?

> (4) implies that I still want exception types so I can
> recover when possible, but there must be a way of
> getting the OS error code.

What if there's not an OS error code?

William E. Kempf
wekempf_at_[hidden]