Boost logo

Boost :

From: David Bergman (davidb_at_[hidden])
Date: 2002-11-21 13:04:16

I have always interpreted "non-localized" as "comprehensible to some 60%
of scientifically inclined Americans" ;-)


-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of William E. Kempf
Sent: Thursday, November 21, 2002 12:08 PM
To: boost_at_[hidden]
Subject: Re: [boost] Do we need a boost_exception class or idiom?

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
>> 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
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
> additional pieces of information it holds. The what() -> format string
> map knows that, too. Sometimes it's good design to not burden the
> 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
>> 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
while Dave's suggestion requires a much more complex specification of
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

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at