The Right Approach to Exceptions

[H. S. Teoh]

On Mon, Feb 20, 2012 at 06:38:08PM -0600, Andrei Alexandrescu wrote:
[...]
> >We shouldn't be using Variant[string] for this, because there's
> >another problem associated with it: suppose MyException sometimes
> >gets "extra_info1" and "extra_info2" tacked onto it, on its way up
> >the call stack, and sometimes not. Now what should the catcher do?
> 
> Use a central loop to render the information.

Then it's useless for i18n, unless you can magically translate a
sequence of unknown values into a different language in a consistent
way.

It sounds like all this is good for is to print a list of "name=value"
pairs. Which is useful, I'll admit, for development/debugging purposes.
I don't see how such a thing is useful in i18n.


[...]
> >This is what I mean by not being able to depend on whether some data
> >is there. Ultimately, to do anything useful with the info in the
> >object, you need to know what's there.
> 
> No. You do realize you are positioning yourself straight against every
> OO principle there is? The entire OO world is predicated on the
> assumption you _can_ do useful stuff with an object WITHOUT knowing
> what's there.

And the way OO does this is by having the *derived classes* do useful
stuff behind a polymorphic interface. What the Variant[string] does is,
as you have said previously, to replace the need for many derived
classes save a few, thereby throwing away the polymorphism and
presenting what amounts to an array of void* to the catch block.

For you to now accuse me of going against OO principles is a really
strange argument, I must say. I was in fact *advocating* the use of OO
by putting the useful information in the derived classes, where they
belong.


> >Preferably, the object's type will tell you exactly what's there,
> >then you do a simple map from type to list of available attributes
> >(e.g., map exception type to format string with known, static list of
> >attributes). But if the type doesn't guarantee what data will be
> >present, then your code becomes vastly more complex, you have to deal
> >with potentially all possible combinations of what's there and what
> >isn't.
> 
> I think you are misunderstanding the mechanisms involved. There is no
> combinatorial code, just simple iteration and such. Dealing with
> distinct exceptions with distinct code IS combinatorial, repetitive,
> and non-scalable.

Then pray tell how "simple iteration" will achieve the translation of
the data in Variant[string] into a localized string, when there is no
guarantee any field will be in the hash at all. Format strings obviously
won't work, since you can't have a format string unless you already know
what arguments are present.

Or are you just going to individually print out "name=value" pairs? In
which case, we've been talking at cross purposes. There is no i18n here
at all.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley