The Right Approach to Exceptions

[Andrei Alexandrescu]

On 2/20/12 4:46 PM, foobar wrote:
> 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.

Not at all. It simply exposes information for any rendering purposes. In 
fact I imagine a simple renderer would just display to the developer the 
message formatted as a simple table with <name, value> for each property.

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

Sure. The question is whether reflection is enough. Juan made the case 
that dynamic paths would want to enhance an exception with additional 
information. Using reflection for that would be forced.

> 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!

Yah, full-blown RTTI would be a fair amount more.


Andrei