The Right Approach to Exceptions

[Juan Manuel Cabo]

> Do you have actual use
> cases that requires adding data to exceptions? Without concrete examples
> we're just arguing about hypotheticals.

I posted a few hypothetical cases during in the thread, but this is one
long megathread!

I'm not facing an urgent need right now for the Variant[string] capability.

I just realized that the majority of twisted exception hierarchies are
grown trying to encode transversal traits of the exceptions in their
types names.

The exception types should encode only one thing: the error *what*.

Now, for real use cases for the Variant[string], you just have to look
around and they are everywhere.

For instance: a C library wrapper, which gets the library errors encoded
as some error code and throws them as exceptions. Shouldn't the library
throw a FileNotFoundException when that's the error, instead of throwing
a LibraryException that has the error code in a field?

So the correct thing to do is: after a library call, the wrapper
checks the last error code number with a switch statement, and deciding
which standard exception type to throw (defaulting to whatever you like
if the error code doesn't map to a standard D exception). Then you
add the error code to the Variant[string].


That way, exception types can be standard.

So, to keep D exception types standard reusable and respected by
future code, you must follow the Open-Closed design principle
(nicest principle of OO design ever).

--jm



On 02/20/2012 07:57 PM, H. S. Teoh wrote:
> On Mon, Feb 20, 2012 at 07:44:30PM -0300, Juan Manuel Cabo wrote:
> [...]
>>> (2) It's overly flexible. Anyone along the call stack can insert
>>> (hopefully NOT delete!!) additional data into the Exception object, as
>>> the stack is unwound. 
>>
>> As is currently the case.
>> Did you know that anyone can overwrite any field of the exception and
>> rethrow it? Such as msg field and so on?
> 
> This is an implementation bug. Exceptions should always be const in the
> catch block. I believe this issue has been filed, and will eventually be
> fixed.
> 
> 
>>> By the time it gets to the final catch() block, you cannot guarantee
>>> a particular field you depend on will be defined.
>>
>> If you want to guarantee it, then use a plain old variable for that
>> piece of data.
>>
>> I just would like a way to add data to an exception without creating a
>> new type.  If I create a new exception type for the wrong reasons, I'm
>> polluting the exception hierarchy.
> 
> Point taken.
> 
> So I think what we should have is *both* data stored in fields in
> Exception subclasses, and some kind of way to attach auxilliary data to
> the exception. Say with Variant[string], or whatever way you prefer.
> 
> But Variant[string] should not be used for *everything*. That only leads
> to problems. But then, it limits the usefulness of Variant[string],
> because then you can't just pass it to the i18n formatter, since now
> some fields are static but they may need to be part of the formatted
> message.
> 
> So we haven't really solved anything, we just added a new feature to
> Exception which I'm not sure how useful it is. Do you have actual use
> cases that requires adding data to exceptions? Without concrete examples
> we're just arguing about hypotheticals.
> 
> 
> T
>