Beman Dawes said:
> 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.

That's what I'm proposing.  A seperate exception for each error condition.
 Under that scheme, I'm not sure I see any use for a code, native or not.

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

Well, I can agree that the cost is low... so I won't argue too much about
including it.  I just want to feel comfortable with the rationale.

William E. Kempf
[EMAIL PROTECTED]


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

Reply via email to