The Right Approach to Exceptions

[deadalnix]

Le 21/02/2012 03:33, Robert Jacques a écrit :
> On Mon, 20 Feb 2012 15:21:56 -0600, H. S. Teoh <hsteoh at quickfur.ath.cx>
> wrote:
>> On Mon, Feb 20, 2012 at 02:57:08PM -0600, Andrei Alexandrescu wrote:
>>> On 2/20/12 1:45 PM, Jonathan M Davis wrote:
>>> >On Monday, February 20, 2012 20:42:28 deadalnix wrote:
>>> >>Le 20/02/2012 20:27, Jonathan M Davis a écrit :
>>> >>>On Monday, February 20, 2012 11:15:08 H. S. Teoh wrote:
>>> >>>>That's why I proposed to use runtime reflection to scan the
>>> exception
>>> >>>>object for applicable fields. Then you get the best of both
>>> worlds: the
>>> >>>>message formatter doesn't need to know what the fields are, and
>>> you get
>>> >>>>full compile-time type checking for catching code that directly
>>> accesses
>>> >>>>the fields.
>>> >>>
>>> >>>That would certainly be better.
>>> >>>
>>> >>>- Jonathan M Davis
>>> >>
>>> >>This is way better than Variant[string], but unimplemented ATM.
>>> >
>>> >Yes, but you can use compile-time constructs to generate it. And as you
>>> >pointed out in another post, tupleof should do the trick.
>>> Regardless, the
>>> >point is that using reflection of some kind is a much better
>>> solution than
>>> >using variant.
>>>
>>> Agreed. Ideally adding a sort of mixin to any class would enable it
>>> for advanced run-time information:
>>>
>>> class DRoxException : Exception
>>> {
>>> mixin(enableRTTI);
>>> ... normal implementation ...
>>> }
>> [...]
>>
>> Doesn't this need compiler/language support?
>
> Nope. See (https://jshare.johnshopkins.edu/rjacque2/public_html/ )
>
> Variant e = new MyException();
> writeln( e.filename, e.line, e.column);
>
> Aren't __traits and opDispatch fun?

opDispatch is nice, but rather incomplete. It doesn't handle template 
methods for example.