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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-09 17:05:41

> From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "William E. Kempf" <wekempf_at_[hidden]>
> > > 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 won't it become relevant when you add the thread attributes?

Actually, yes... I missed that.  In the current code I glossed over this by throwing a generic runtime_error in the one place this occurs.  So... make that currently 5 exception types needed (with a possible 6th if you want to distinguish memory and other resources).
 
> MSDN doesn't really say whether it's possible to get ERROR_ACCESS_DENIED
> from thread functions but I wouldn't rule out the possibility. :-)

They don't say it directly... but it's heavily implied.  I'd be floored if that were not a possibility.  (In case you don't get the implication... it comes from CreateThread taking a security attribute.)
 
> > 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?
> 
> I believe I answered this question below. No, it is not better to lump the
> different errors into a single exception. Separate exceptions are fine.

Yes, you answered below.  Sorry... I usually reply as I read as a bad habit.
 
> > (And is it useful to distinguish between memory and other resource
> errors?)
> 
> This, I have no ready answer for... but "when in doubt, do what POSIX does."

Why (in regards to "do what POSIX does")?  They can make mistakes as easily as the rest of us.

If we do seperate them, is there any reason to provide a thread specific memory exception, or should we use std::bad_alloc?

> > > 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.
> 
> The easiest is to simply return e.g. "boost::thread_resource_error" from
> what(), but it might prove controversial. :-)

Not to me ;).
 
> > > 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.
> 
> An error code (OS or portable) can be of help when one needs to catch all
> thread-related (or better yet, all error code providing) exceptions in a
> single catch clause. Usually this is only needed to report an error, though,
> so if thread exceptions provide some other common mechanism to identify the
> error (like specific what() values), carrying an error code won't be
> necessary.

And would the above mentioned  "localized message" be enough to satisfy this requirement?

William E. Kempf
wekempf_at_[hidden]