The Right Approach to Exceptions

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Feb 20 11:57:12 PST 2012


On Mon, Feb 20, 2012 at 02:45:25PM -0500, 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.
[...]

I agree, we should use tupleof for this purpose.

I always view Variant has a last resort hack that we should only use if
there's absolutely no other way around it. The lack of compile-time type
checking on Variant makes it prone to nasty issues like everything
compiling with no error and then blowing up at runtime. This is
especially bad in code related to exceptions, because they are by
definition exceptional, so problems like these often won't get caught
until they crash the customer's production server.


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.


More information about the Digitalmars-d mailing list