Re: Re: [boost] Re: Next revision of boost::thread

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-09 16:13:57

> From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "William E. Kempf" <wekempf_at_[hidden]>
> >
> > OK, I've been looking at boost::filesystem_error.  Here's my thoughts:
> >
> > boost::filesystem_error could be benefited by splitting it up into more
> > exception types.  I know this was suggested in the review, but don't know
> > what the plan was in regard to this.  In Boost.Threads case, so far we
> have
> > need for 4 different errors: lock errors, resource errors, invalid
> arguments and
> > unsupported errors.
> 
> POSIX actually distinguishes out of memory errors (ENOMEM) from other lack
> of resource errors (EAGAIN), and POSIX functions can fail with an "access
> denied" error (EPERM).

EPERM is not an issue (I believe) for anything in Boost.Threads (yet).  But this doesn't really answer my basic question.  Is it better to carry these error codes in a single exception, or have multiple exception types?  (And is it useful to distinguish between memory and other resource errors?)
 
> There are also several types of POSIX lock errors (EINVAL, EBUSY, EAGAIN,
> EDEADLK, EPERM.) Boost.Threads has two additional lock errors associated
> with the Lock concept that have no POSIX equivalent.

Yep.

> > Some have suggested carrying the OS error code, but given only 4 possible
> error
> > conditions, does this even sound reasonable?
> 
> If the reason for the failure can be identified by the type of the
> exception, there should be no immediate need to carry an OS error code,
> although you should consider the "how do I translate this to a localized
> error message" problem.

Any suggestions on that one?  I haven't really seen any viable answers provided yet.
 
> > Or are people
> > suggesting Boost.Threads should use a single exception type and carry the
> error
> > code, as filesystem_error currently does?
> 
> No, this would be a step backward. IIUC filesystem_error is expected to
> evolve into a hierarchy as exception categories of interest to callers are
> identified.

Then why *ever* carry the OS error code.  The exception type would likely mirror every OS error code possible (with some folding, where appropriate, where I'd expect the precise code to be irrelevant).  I don't understand what the OS error code would add.
 

William E. Kempf
wekempf_at_[hidden]