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, 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
