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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-09 12:13:25

"Peter Dimov" <pdimov_at_[hidden]> writes:

> 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

There might be, depending on how the implementation handles the
std::string argument, and when you create these exception objects.
The standard exception hierarchy is sticky.

> 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).

I think I'm going to recommend that we throw an exception type which
uses virtual derivation from std::exception.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution