The Right Approach to Exceptions

[Andrei Alexandrescu]

On 2/20/12 1:41 PM, Sean Kelly wrote:
> Localized error messages are typically generated by a localization
> team and placed in some sort of a lookup table, indexed by language
> and error code.  Say the code is roughly like this:
>
> displayLocalizedError(Exception e) { auto t =
> loadTable(e.info["lang"]); // info["lang"] returns "ja" for japanese,
> etc. string m = t.findMessage(typeid(e).toString);
> writeln(buildLocalizedMessage(m, e.info)); }

I'd amend your example a bit as follows:

displayLocalizedError(Exception e) {
     auto t = loadTable(g_lang); // g_lang contains "ja" for japanese, etc.
     string m = t.findMessage(typeid(e).toString);
     writeln(buildLocalizedMessage(m, e.info));
}

I mean the exception has no notion of "lang"uage.

> Where m (in english) may be something like:
>
> "Saving to {LocationType} {!LocationName} failed because the
> destination is full."
>
> The message is parsed and when {LocalizationType} is encountered, the
> parser knows to replace it with another localized string indexed by
> "LocationType".  Then {!LocationName} is replaced by
> e.info["LocationName"], which is specific to the actual error that
> occurred.  In essence, each line that has to be localized has a
> monetary (and time) cost for doing so, so error lines are reused when
> possible.  Then specifics that may or may not themselves be localized
> are potentially pasted in to generate the final message.

Yup, yup, and yup.


Andrei