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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-11-21 13:45:29

Peter Dimov said:
> From: "William E. Kempf" <wekempf_at_[hidden]>
>>
>> Peter Dimov said:
>> > From: "William E. Kempf" <wekempf_at_[hidden]>
>> >> In fact,
>> >> in most cases they are user supplied, instead of implementation
>> supplied.
>> >
>> > User supplied what() strings? In most cases?
>>
>> Every standard exception from logic_error or domain_error down are
>> constructable only through a constructor that takes a string and sets
>> the value to be returned by what().  (User exceptions derived from
>> these are obviously open to not follow this lead.)
>
> 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.)

>> >> The main problem I see with this approach is that any existing code
>> that expects what() to return a human readable (albiet unlocalized)
>> string will now be getting a string that's not easy to decipher.
>> >
>> > A string cannot be said to be human readable if it's not localized.
>> Would you consider a string in Bulgarian human-readable?
>>
>> Certainly, to a Bulgarian.
>>
>> But what was meant was that I'd prefer to leave what() as is, with
>> non-localized but readable strings, and provide a seperate key() for
>> use in retrieving a localized message.
>
> 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.

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

2) I don't necessarily mean that the non-localized string will be in
English by default.  The implementor can use what ever language they want
to here.

Other than that, I'd agree with your analysis.

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

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

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.

William E. Kempf