The Right Approach to Exceptions
SeeWebsiteForEmail at erdani.org
Mon Feb 20 15:22:13 PST 2012
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?
More information about the Digitalmars-d