> 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
