> From: Beman Dawes <[EMAIL PROTECTED]> > 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.
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 [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
