The Right Approach to Exceptions

[Andrei Alexandrescu]

On 2/20/12 3:06 PM, Juan Manuel Cabo wrote:
> I like one golden rule that I have:
>
>   "You should only create a new exception type, if it makes sense to write
>    a  catch(MyNewShinyType ex){}  "

The problem with this is that anyone may come with an example created on 
the spot where they would, actually, want to catch a specific exception. 
It's very hard to make non-existential proofs.

> other reasons for creating a new exception class I don't consider them valid
> (but that's just me!).
> This is because, exception types (in my head) are only a way to distinguish
> whether to select them or let them go when I write a catch(), and to
> help the catch recover.  Now, if I can't distinguish the *what* of the error,
> I cannot recover well. The *cause* of the error goes inside the exception
> object, not encoded in the type. Other details of the error go inside of
> the exception object, not encoded in the type name.
>
> So all I care about is the *what* of the error, so that it will fall in
> the correct catch statement. Other criteria obscures that.
>
> The Variant[string] helps keep the hierarchy clean. The hierachy should
> tell the *what* of the error so that I can pick one when writing a catch block.

Don't forget that you always have the option of creating a type on the spot.

void fun()
{
    if (oops)
    {
        class MyException : Exception
        {
           string reasonForOops;
           ...
        }
        throw new MyException; // RTTI will find reasonForOops
    }
}

But after seeing a variety of pros and cons, I tend to agree that the 
Variant[string] is more attractive.


Andrei