The Right Approach to Exceptions

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:jhu7kj$1mae$1 at digitalmars.com...
> "Nick Sabalausky" <a at a.a> wrote in message 
> news:jhu61p$1jpm$1 at digitalmars.com...
>> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
>> news:jhtss8$12mq$3 at digitalmars.com...
>>> On 2/20/12 10:16 AM, Nick Sabalausky wrote:
>>>> "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org>  wrote in message
>>>> news:jhtq31$u8q$1 at digitalmars.com...
>>>>>
>>>>> Again, I think this thread clarified we need the "Variant[string] 
>>>>> info;"
>>>>> member however we define the hierarchy.
>>>>>
>>>>
>>>> I disagree. I don't see a need for that.
>>>
>>> How would we address custom formatting of e.g. error messages?
>>>
>>
>> Maybe I've misunderstood your intent for this "Variant[string] info;" My 
>> understanding is that, for example, you want to replace this:
>>
>> ----------------------------------------------------
>> class Exception {}
>> class FooException
>> {
>>    string fooName;
>>    int fooID;
>>    bool didBarOccur;
>>
>>    this(string fooName, int fooID, bool didBarOccur)
>>    {
>>        this.fooName = fooName;
>>        this.fooID= fooID;
>>        this.didBarOccur= didBarOccur;
>>    }
>> }
>> ----------------------------------------------------
>>
>> With this:
>>
>> ----------------------------------------------------
>> 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.
>>
>
> Ok, I just saw your explanation here: 
> http://forum.dlang.org/post/jhu1hk$1cb8$1@digitalmars.com
>
> And, IIUC, I assume that inside "stringTemplate()", you'd then access some 
> table that roughly amounts to (yea, I know we don't have 2D AAs):
>
> string[string, Locale] i18nTable;
> i18nTable["FileNotFoundExcepton", English] = "File ${filename} not found";
>
> Then stringTemplate() would look that up, find the string "File 
> ${filename} not found" and essentially do:
>
> return "File "~e.info("filename")~" not found";
>
> Although obviously not hardcoded like that.
>
> Is that right?
>
> In that case, I like the general idea, *but* why not just use reflection 
> to access the members instead of essentially creating a JS-style "class" 
> with AAs? That way we don't have to either A. throw away the benefits that 
> class members have over AAs or B. violate DRY by duplicating field members 
> in an AA.
>

Using reflection instead of "Variant[string] info" has another benefit: It 
allows the i18n table to *automatically* support any type, not just 
Exceptions. By contrast, with "Variant[string] info", a member has to be 
explicity (or via inheritance) added to every type that the i18n table wants 
to handle. So you're actally *creating* unnecessary cupling with i18n by 
using "Variant[string] info". If you replace "Variant[string] info" with 
reflection, then you've *completely* factored out i18n.

Admittedly, if the i18n engine populates its tables at runtime, then the 
reflection would have to be runtime reflection, and I don't know offhand if 
we currently have that particular form of runtime reflection yet or not. But 
if not, then this is a good use-case for why it should get implemented 
sooner or later.