I have always interpreted "non-localized" as "comprehensible to some 60% of scientifically inclined Americans" ;-)
/David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of William E. Kempf Sent: Thursday, November 21, 2002 12:08 PM To: [EMAIL PROTECTED] Subject: Re: [boost] Do we need a boost_exception class or idiom? Peter Dimov said: > From: "William E. Kempf" <[EMAIL PROTECTED]> >> >> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost