The Right Approach to Exceptions

Robert Jacques sandford at jhu.edu
Mon Feb 20 18:33:18 PST 2012


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?


More information about the Digitalmars-d mailing list