From: William E. Kempf [mailto:wekempf@cox.net]
>> ... 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?

When there is not a one to one mapping of library errors and native
errors having both may be useful for platform specific recovery.

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

It could be potentially be useful in a scheme where exceptions can
be propagated across threads to the joiner.

Glen