Re: [boost] Re: Next revision of boost::thread & OS error code.

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-13 16:24:45

"William E. Kempf" <wekempf_at_[hidden]> writes:

> David Abrahams said:
>> "William E. Kempf" <wekempf_at_[hidden]> writes:
>>
>>> David Abrahams said:
>>>> "William E. Kempf" <wekempf_at_[hidden]> writes:
>>>>
>>>>>> People said they wanted it, and the cost is low (one int). I think
>>>>>> Greg is  right that they wanted to attempt system-dependent
>>>>>> recovery.
>>>>>
>>>>> Well, I can agree that the cost is low... so I won't argue too much
>>>>> about including it.  I just want to feel comfortable with the
>>>>> rationale.
>>>>
>>>> I think a rationale goes like this:
>>>>
>>>> suppose the platform gives you a function for converting an error
>>>> code into an error message (realistic, I think).  How much code do
>>>> you have to write in order to take advantage of it?
>>>
>>> Contrasted with, "If a platform has the ability, the error is
>>> translated into a message that's returned as part of what()."  That's
>>> where I feel uncomfortable with the reationale.
>>
>> Remember that it's a bad idea to carry dynamically-allocated state in an
>> exception object.  Translating to readable strings at the throw point is
>> ill-advised.
>
> Agreed, but that's an implementation detail.  IOW, the exception should
> carry the error code, but what purpose is there in having the interface
> expose this detail?
>
> BTW:  The filesystem_error carries a lot of dynamically-allocated state
> (as in 1/2 of the member data is, at least potentially, allocated).

Lots of platforms have callback interfaces where if the callback fails
it may need to pass an error code back to the caller.  If you couldn't
easily get the original error code back this could be a serious pain.

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