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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-16 12:28:26

From: "William E. Kempf" <wekempf_at_[hidden]>
> Peter Dimov said:
[...]
>
> But if every level of the call stack does such a translation, there's no
> need for who() to begin with.  open_file() knows it was thrown by
> is_directory(), because it called is_directory().  change_config() knows
> it was thrown by open_file(), because it called open_file().  And on up
> the call stack.

Correct. But not every level of the call stack needs to do such a
translation... and in practice, I'd expect that no translation would be
necessary at all for a typical filesystem implementation.

> > who() is not the _exact_ function name that has thrown the exception. It
> > identifies the action that failed, using documented function names as
> > idetifiers. As a QoI issue, the library will return a who() string that
> > is the best representation of the action that failed.
> >
> > In particular, if open_file() calls, under the hood,
> > detail::open_file_impl, it should _not_ throw exceptions with
> > "detail::open_file_impl" as a who() string.
>
> I.e. you advocate who() only relying upon the implementation to change the
> value as it moves up the call stack (whether that be a conceptual call
> stack or a physical program call stack matters little here).  As long as
> you're doing that... I see nothing that who() provides that's not already
> present in the program context, as I pointed out above.

No, I don't advocate anything like that. In the above example
detail::open_file_impl would throw an exception with who() == "open_file";
it is not allowed to use an undocumented function name. There would be no
need for any translation.

Translation is only necessary when a documented library function calls
another documented library function as an implementation detail _and_ the
failed action would be better described by the caller name, not the callee
name.

Such situations may indicate problems with the library design.

[...]

> > Using an undefined "recover" verb is typical for such discussions. :-)
> >
> > No, I don't want to recover. I want to inform the user what happened.
>
> Recovery still takes place here.

If you insist. Using undefined terms allows you to make all sorts of
statements.