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

[Beman Dawes]

At 11:18 AM 1/10/2003, William E. Kempf wrote:
>> From: David Abrahams <[EMAIL PROTECTED]>
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
>> >> From: Martin Brown <[EMAIL PROTECTED]>
>> >>
>> >> 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.

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.

--Beman


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost