The Right Approach to Exceptions

[Andrei Alexandrescu]

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