On 2/20/12 4:25 PM, Jonathan M Davis wrote:
In my experience, the type is very much tied to the context.
I thought you said the type is tied to "what happened, not where it happened", which is the polar opposite of the above.
When a particular type of error occurs, there's a particular set of information that goes with that, and that doesn't generally change. So, you don't end up with a bunch of types which are solely there to add additional information.
But on the way up there's additional contextual information. "Total amount must be a positive number" is more descriptive "Conversion error", although it originated as the latter. Insisting that all that must be encoded as types seems overly rigid, not to mention non-scalable.
Using variant means moving to dynamic typing and problems that you don't see until runtime, whereas having the data as direct member variables is statically checked.
That's a given. However I think the most frequent use of exception interfaces is to extract data for formatting purposes, and the exception interface would do good to help with that.
Having the ability to add extra information via Variant[string] may not be a problem, but doing that for everything _would_ be. It's far more bug prone, and the fact that it would be error handling code which would have the bugs would make them _far_ harder to catch and fix. I definitely think that we should favor putting data in member variables, not in a hashtable of Variants.
Whenever you put data in member variables you set yourself up for code bloat. Do you agree?
Andrei
