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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-01-10 16:22:25

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.

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