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.
