From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-01-09 15:39:44
At 01:32 PM 1/9/2003, William E. Kempf wrote:
>> From: "William E. Kempf" <wekempf_at_[hidden]>
>> > From: "Stefano Delli Ponti" <stefano.delliponti_at_[hidden]>
>> > From: "William E. Kempf" <wekempf_at_[hidden]>
>> > > > From: "Stefano Delli Ponti" <stefano.delliponti_at_[hidden]>
>> > > > 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.
>> > > >
>> > > > Agreed. And we should keep coherence with the filesystem library.
>> > >
>> > > I'm not sure there's any coherence to keep here. Do you have specific
>> > concerns/thoughts here?
>> >
>> > I was thinking about keeping similar design patterns between these two
>> > libraries.
>> > (because they are conceptually similar as they both give a portable view of
>> > operating system functionalities).
>> > So if we use domain specific exception in the filesystem library, the thread
>> > library should follow the same pattern too. The same for the issue of
>> > conditional compilation.
>>
>> I'll look at this closer, but the domains are different enough that I'm not sure there's anything that carries over.
>
>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. Some have suggested carrying the OS error code, but given only 4 possible error conditions, does this even sound reasonable? Or are people suggesting Boost.Threads should use a single exception type and carry the error code, as filesystem_error currently does?
I think it depends on how useful the four different types and the OS
error code are for recovery purposes.