The Right Approach to Exceptions

[H. S. Teoh]

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

-- 
This is not a sentence.