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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-11-21 12:07:32

Peter Dimov said:
> From: "William E. Kempf" <wekempf_at_[hidden]>
>>
>> David Abrahams said:
>
> [...]
>
>> >>>   std::map<char const*, std::string, compare_cstring>?
>> >>
>> >> This assumes that the what() strings are all unique,
>> >
>> > Show me another solution which doesn't rely on a similar assumption,
>> please.
>>
>> The problem is that the what() strings aren't enforcably unique.
>
> True, they are not. This is exactly the problem, as I see it.
>
>> 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.)

> [...]
>
>> >> // hypothetical code...
>> >> try
>> >> {
>> >> ....
>> >> }
>> >> catch (const boost::exception& e)
>> >> {
>> >>    std::string str = lookup(e.key());
>> >
>> >   catch(std::exception& e)
>> >   {
>> >      std::string str = lookup(e.what());
>> >
>> >>    // 'str' no contains a locale specific string with replacable
>> value
>> >> // markers, for instance:
>> >>    // "bad_argument '${argument}' thrown in ${function}"
>> >>    std::cout << e.format(str) << std::endl;
>> >
>> > Why go back to the exception object to do the formatting job here?
>
> Sometimes it's indeed useful to do that. The exception object knows what
> additional pieces of information it holds. The what() -> format string
> map knows that, too. Sometimes it's good design to not burden the catch
> point with that knowledge.
>
>> > I think you can encode all of that stuff into the what() strings:
>> >
>> >   "bad_argument$3$my_function\0"
>>
>> That might be another approach, but would require strict specification
>> of what's returned from what(), and a more complex lookup/format
>> mechanism.
>
> Yes, you hit the nail on the head. "Strict specification of what's
> returned from what()" is indeed what is needed.

To elaborate on what I meant, the solution I gave required only that
what() return a unique value for which localized strings can be looked up,
while Dave's suggestion requires a much more complex specification of what
may be returned from what() (as in, specific formatting will be required
so the lookup mechanism can extract the needed data for formatting).

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

William E. Kempf