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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-15 04:11:09

Peter Dimov said:
> From: "William E. Kempf" <wekempf_at_[hidden]>
>>
>> Peter Dimov said:
>> > From: "William E. Kempf" <wekempf_at_[hidden]>
>> >>
>> >> Might be true for Boost.Filesystem.  The path values may be useful
>> in some cases, for instance.  I'm not 100% sure about the who()
>> string, though.
>> >
>> > The meaning of the path values is context dependent, and who()
>> provides the context, although perhaps who() doesn't need to be a
>> std::string, a const char * could do. (If the current what()
>> semantics are dropped, what() can be made to carry the function name
>> ("what failed"), and who() will become redundant.)
>>
>> If what returns the function name that caused the exception, replacing
>> who, you've not eliminated dynamic allocations where they matter.
>>
>> But I don't understand the utility of who(), i.e. what good is it to
>> get a single function name that originated the error?  The user isn't
>> going to care about this information, and the developer is going to
>> want a call stack, not the originator (which may be buried several
>> calls deep in the interface the developer is actually dealing with!).
>> I don't understand the value add for this payload.
>
> I've already went over this a couple of times. :-)
>
> The fact that who() returns a function name is not important; it is not
> a "mini call stack". A function name is used as a token that identifies
> the point of failure. What failed? An attempt to open a file? An attempt
> to read the contents of a directory? An attempt to copy a file? To move
> a file? You need this information in order to compose a meaninful error
> message. "No such file or directory" by itself isn't very helpful to the
> user. What is the name of the file/directory that wasn't found? What did
> the program try to do with it?

But the "who" is dependent on higher level information than what's
available to the library.  Knowing that "no such file or directory" was
thrown by "open_file" doesn't help the end user when the action he took
was to change a configuration option, for instance.  And it's no use to
the programmer to log such information if it's not also logged that the
user was trying to change the configuration at the time, otherwise there's
likely several points in the application that could have failed.

Good error handling will either catch the exception as close to the point
of error as possible, where there's enough known context to give a
meaningful report, or will log much more information then is available to
the point of exception generation (at least in a portable manner).  I
can't see how who() is helpful.

> Once you accept that the exception needs to provide an unique token that
> identifies the point of failure, now the question is how to choose its
> type and value.

But I don't accept that, unless the FULL point of failure can be
identified (i.e. a call stack).

William E. Kempf
wekempf_at_[hidden]