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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-09 11:11:25

From: "William E. Kempf" <wekempf_at_[hidden]>
> > From: David Abrahams <dave_at_[hidden]>
> > "William E. Kempf" <wekempf_at_[hidden]> writes:
> > >> From: David Abrahams <dave_at_[hidden]>
> > >> "William E. Kempf" <wekempf_at_[hidden]> writes:
> > >>
> > >> > That's a good idea.  So would users prefer new exception types
here,
> > >> > or should I use the std:: exceptions?
> > >>
> > >> IMO, it's always safer to use an exception type which provides
> > >> more-specific information.
> > >
> > > What extra information do you want provided?
> >
> > For example, that it was a threading library exception.  Information
> > carried by the type identity may be enough.
>
> It's the "may" that concerns me here.  I have absolutely no problem using
a
> domain specific exception type here... I just want to insure doing so
covers _all_
> the needs.

I don't see any drawback in throwing something derived from
std::runtime_error, and not std::runtime_error itself. This lets you provide
more information for clients that catch(thread_error) and still lets others
catch(std::runtime_error).

As for the extra information, on POSIX it would be a good idea to provide
the errno-compatible error code returned by pthread_*, and it _might_ be a
good idea to supply a portable error code, too, as the filesystem library
does.

When I suggested that we adopt <cerrno> values as the portable error code, I
had the following in mind. It would be possible to catch thread and
filesystem exceptions with a single catch clause if they share the same
error code function... although I'm not yet sure whether this is necessary.