The Right Approach to Exceptions

foobar foo at
Mon Feb 20 14:46:08 PST 2012

On Monday, 20 February 2012 at 21:02:21 UTC, Andrei Alexandrescu 
> On 2/20/12 2:01 PM, foobar wrote:
>> Seconded. Reflection seems a much better solution for this.
> Absolutely.
>> The i18n table would map (exception type) -> (language, format 
>> string)
>> and the i18n formatter would use reflection to map field 
>> values to the
>> format string.
>> a format string would be e.g. "File {filename} not found" and 
>> the
>> formatter would replace {filename} with 
>> e.class.getField("filename").
>> This does not require any modifications to the exception 
>> mechanism.
> Yah, but the reflection engine would have to present RTTI in a 
> uniform manner... such as, Variant[string]. Bane of my life: 
> I'm always right :o).
> Andrei

Unfortunately you aren't :)
The Variant[string] approach causes coupling between two separate 
concerns: i18n and error handling. Reflection does *not* cause 
such coupling. More over, Reflection is a general language 
mechanism with many benefits such as allowing the user to use the 
i18n library with other non exception types.
Lastly, good RTTI is hardly a simple Variant[string]. Java for 
instance has pretty good RTTI API whereas the c++ one is horrible 
(and incomplete).

Conclusion - *not* the same thing!

More information about the Digitalmars-d mailing list