RE: Re: [boost] Re: Next revision of boost::thread & OS error co de.

From: Glen Knowles (gknowles_at_[hidden])
Date: 2003-01-11 02:52:45

From: William E. Kempf [mailto:wekempf_at_[hidden]]
>> ... what() // from std::runtime_error. Implementation provides
>>            // a very explicit message, including who(), path1(),
>>            // path2(), and message reported by O/S (which is
>>            // subject to locale on some O/S's.
>> 
>> int native_error() const;
>> // a return of 0 implies a library (rather than system) error
>> 
>> error_code error() const;  // filesystem defined error code
>> 
>> const std::string &  who() const; // name of func throwing exception
>> 
>> const path & path1() const; // argument 1 to func; may be empty()
>> const path & path2() const; // argument 2 to func; may be empty()
>> 
>> That's pretty heavyweight, but each function has important uses.
>
>This description brings a better understanding than what I had 
>previously, but doesn't fill in all the gaps.
>
>What's the purpose of a non-native error code?  For that matter, if 
>what() includes a translated message for the error code, what 
>purpose is there for the native error code?

When there is not a one to one mapping of library errors and native 
errors having both may be useful for platform specific recovery.

>> For Boost.Threads, path1() and path2() obviously don't apply, but I 
>> wouldn't be surprised if a string identifying the thread in some way 
>> wasn't a possible need.
>
>The thread will always be the current thread, so there's no need to 
>carry that payload.

It could be potentially be useful in a scheme where exceptions can 
be propagated across threads to the joiner.

Glen