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

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-01-10 17:36:48

At 03:15 PM 1/10/2003, William E. Kempf wrote:
>> From: Beman Dawes <bdawes_at_[hidden]>
>> At 11:18 AM 1/10/2003, William E. Kempf wrote:
>>  >> From: David Abrahams <dave_at_[hidden]>
>>  >> "William E. Kempf" <wekempf_at_[hidden]> writes:
>>  >> >> From: Martin Brown <martin_w_brown_at_[hidden]>
>>  >> >>
>>  >> >> 2. The user needs a localised error message.
>>  >> >
>>  >> > Is the textual representation of the exception name
>>  >> > enough?  If not, how do you propose a library provide
>>  >> > such a localised error message?
>>  >>
>>  >> I will weigh in here with one strong opinion: producing localized
>>  >> error messages should not be the job of the exception object or the
>>  >> code which throws it.  Error message formatting and localization
>>  >> should happen after exceptions are caught.
>>  >
>>  >Full agreement.  But what (if anything) must the exception object
>>  >provide in order for the exception handlers to be able to format
>>  >a localized message?
>> 
>> Peter Dimov and I went back and forth about this for the filesystem library 
>> and decided:
>> 
>>        ... 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?

For platform-specific error recovery?