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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-14 12:11:06

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?

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. Integral constants don't work well since you need arbitration to
prevent collisions. C++ identifiers are a good solution since the compiler
enforces unique-ness. :-)