"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> > From: David Abrahams <[EMAIL PROTECTED]>
>> > "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> > >> From: David Abrahams <[EMAIL PROTECTED]>
>> > >> "William E. Kempf" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
