So, if your boss wants the URL of the request that was made when the standard library threw you a FileNotFoundException, you can do:
try { ... } catch (Exception ex) { //Rethrow the exception with the added detail: ex.details["custom_url"] = getenv("URI"); throw ex; } (don't beat me if URI wasn't the envvar that apache sends for uri, I don't remember it at the moment). --jm On 02/20/2012 04:27 PM, Juan Manuel Cabo wrote: >> 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 >