The Right Approach to Exceptions

[Andrei Alexandrescu]

On 2/20/12 7:08 PM, H. S. Teoh wrote:
> 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.

As I said, string templates in conjunction with name/value bindings is 
all that's needed for 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.

Exactly, and with this you just destroyed your own design. For it does 
not build any polymorphic interface, no abstraction. It forever forces 
code to toil in the concrete (_fileName, _ipAddress, _userName) and 
fails to elevate any common interface that would foster reusable code.

> 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.

On the contrary. This builds abstraction:

class Exception
{
     bool transient();
     Variant[string] info();
     ...
}

because it allows client code to treat different types, even types that 
haven't even been defined yet, uniformly.

This does not build anything:

class Exception {}
class UserNameException : Exception { string _userName; }
class NetException : Exception { string _ipAddress; }
...

> 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.

I'm not accusing of anything, merely noting that your design does not 
stand the scrutiny of your own principles (which are correct). Both 
can't be sustained simultaneously. Try a fresh run of your principles 
over your design. It'll get totaled.

>> 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.

There's no guarantee. That'll be a runtime check in the formatting engine.


Andrei