The Right Approach to Exceptions

Sean Kelly sean at
Mon Feb 20 11:41:05 PST 2012

On Feb 20, 2012, at 11:12 AM, Nick Sabalausky wrote:
> ----------------------------------------------------
> class Exception
> {
>    Variant[string] info;
> }
> class FooException
> {
>    string fooName;
>    int fooID;
>    bool didBarOccur;
>    this(string fooName, int fooID, bool didBarOccur)
>    {
>        this.fooName = fooName;
>        this.fooID= fooID;
>        this.didBarOccur= didBarOccur;
>        info["fooName"] = fooName;
>        info["fooID"] = fooID;
>        info["didBarOccur"] = didBarOccur;
>    }
> }
> ----------------------------------------------------
> If so, then I don't see any usefulness of "Variant[string] info" other than 
> to start treating exceptions like JS's abomination of an "object" (Or at 
> least AS2's objects anyway - not 100% certain how much of AS2 is taken from 
> JS). If not, then could you clarify what you meant?
> In either case, I am interested to hear in more detail how you see 
> "Variant[string] info" being used to address i18n. I haven't really dealt 
> with a lot of i18n myself.

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(["lang"]); // info["lang"] returns "ja" for japanese, etc.
    string m = t.findMessage(typeid(e).toString);

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

More information about the Digitalmars-d mailing list