At 05:15 PM 1/10/2003, William E. Kempf wrote:

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

It is useful for those who want a portable, more detailed breakdown of what caused the error. The alternative was no non-native error code, but instead providing one exception class for each of what are now error codes.

> For that matter, if what()
>includes a translated message for the error code, what purpose is there for
>the native error code?

People said they wanted it, and the cost is low (one int). I think Greg is right that they wanted to attempt system-dependent recovery.

Note that there is no requirement on what(). As a QOI I tried to deliver a very informative message, but don't want to try to mandate that. Also, whether the localized message actually is in the right language for the user depends on a lot more than what the O/S thinks is the right locale.

>The thread will always be the current thread, so there's no need to carry
>that payload.

Duh!

--Beman

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

Reply via email to