The Right Approach to Exceptions

[Juan Manuel Cabo]

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
>