Re: [boost] Do we need a boost_exception class or idiom?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-11-22 07:10:11

From: "William E. Kempf" <wekempf_at_[hidden]>
>
> Peter Dimov said:
> >
> > I see, ambiguous usage of "user". Let's rephrase: in most cases the
> > what() string is supplied by the throw point, not the catch point,
> > right? I.e. library authors decide what to return from what(), library
> > users do not.
>
> Except it's not just libraries that throw, and in some corner cases
> libraries have to deal with exceptions thrown by user code.  (Whether or
> not it's appropriate for library code to do logging in these cases is
> questionable, however.)

That's correct (Boost.Threads eating thread exceptions immediately comes to
mind ;-) ) but how does this affect our discussion?

> > I understood that, too. My point was that "non-localized but readable
> > strings" is meaningless, unless you define what "readable" means.
> > Readable to a Bulgarian? Readable to at least 26% of the audience?
> > Readable to whoever we consider important?
>
> Mostly the latter, which to me mostly means the programmer.  We can bear
> the burden of having to interpret a non-localized string, even if it's not
> in our native language.

The interesting thing to note here is that to the programmer
"boost::thread_resource_error" is just as readable as "Required thread
resource is unavaliable." Sometimes the former is _more_ readable, if the
programmer's native language is not English.

> > Please do understand that I'm just trying to provide some perspective
> > here. Of course I know what the intuitive meaning of "readable but
> > non-localized" is - English text. English-speaking countries have earned
> > that right, WRT computers. Still, an international standard should be,
> > well, international.
>
> 1) I wasn't proposing a change to the standard here.  I think it's
> premature to be looking at that.  Fix the issue of memory allocation
> requirements on the standard provided exceptions and I think you've done
> enough as far as the standard is concerned.

The exception issue is too broad; it simply cannot be "fixed" by local
changes. Application X has to deal with exceptions thrown by the standard
library implementation, by third party libraries Y and Z, by low-level
libraries (some of them Boost, some not) used by Y and Z...

If we aren't aiming for a standard fix, I'm not interested. It simply will
not make my job easier.

> > There's also the additional problem that the current what(), if left
> > as-is, does not guarantee, and often does not produce, an useful
> > readable string, even if we accept the above "readability" definition.
>
> Well, other than the fact that the what() text is user specified, I'd
> consider this a QoI issue and not that important.  Especially if there's a
> mechanism available for the user to specify what the message will be in a
> localized fashion.

Application programmers that need to actually do something with that what()
string consider the problem important. When you receive a bug report related
to a text that your application displays, you can't shrug it off claiming
that this is a QoI issue in a standard/Boost/third party library. You need
to fix the problem.

> >>From a technical point of view, it's obviously easier to just leave
> >> what()
> > as is (i.e. of questionable utility outside of toy programs), introduce
> > another function, and get it right this time.
>
> I'd tend to agree, but the question is still how to design it so that it's
> "right this time".

My answer is that specifying the precise semantics of what() for every
documented exception type is a necessary prerequisite. (Implies that the
standard needs to be fixed, too.)

> And to be fair, it is a valid argument that logging for exceptions is
> something outside of the domain of exception propagation and handling.  We
> could never touch the what() method but instead build an elaborate scheme
> of mapping type_info to localized messages for logging with out having to
> change the design of the exceptions at all.  I personally don't like that
> answer, but from the standards point of view it might be the correct
> answer.

To repeat, type_info instances make a good default, but they cannot be used
as is. Sometimes different logical exceptions are represented by the same
physical class. Sometimes an undocumented derived class is thrown instead of
the documented base.