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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-10 17:15:10

> 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 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.
 

William E. Kempf
wekempf_at_[hidden]