The Right Approach to Exceptions
foobar
foo at bar.com
Mon Feb 20 14:46:08 PST 2012
On Monday, 20 February 2012 at 21:02:21 UTC, Andrei Alexandrescu
wrote:
> 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