The Right Approach to Exceptions

[Juan Manuel Cabo]

> And so variant is the way to go ?
> 
> Clearly, this is a very strong arguement in favor of typed Exception, that provide usefull information about what went
> wrong. This is a safe approach.
> 
> Because this Variant stuff is going to require massive ducktyping of Exceptions, with all possible errors involved. The
> keys in the Variant[string] will depend on the Exception the dev is facing. This should be avoided and should warn us
> about the requirement of typed Exceptions.


Some of the things that characterize an exception, their traits, are
transversal to any hierachy that you can imagine, now and in the future.

You can choose to keep changing a hierarchy, or build in some mechanism
to the Exception base class, that will allow you to get your traits
without downcasting.

Say that at your place of work the boss decides that all exception classes
should have a COM error code, or that all exception classes should
provide the URL of the request that generated it.

You know what will happen?

Your boss will require you to derive all your exception classes from
COMException or from WebRequestException and then redefine FileNotFound
as a subclass of them. So you will have your FileNotFoundException
different than the standard library exception.

Don't believe me? It happened to .NET... they've got a COMException
that wraps any other kind of error during a COM call.


--jm