The Right Approach to Exceptions

[Andrei Alexandrescu]

On 2/20/12 4:04 PM, H. S. Teoh wrote:
> On Mon, Feb 20, 2012 at 03:12:08PM -0600, Andrei Alexandrescu wrote:
> I still don't like the idea of using Variant[string], though.

I don't like it, either. I mean not "like" like. It's an approach 
suggested by necessity.

> (1) It doesn't allow compile-time type checking. This is a big minus, in
> my book.

In mine, too. Literally. We're on the same boat.

> (2) It's overly flexible. Anyone along the call stack can insert
> (hopefully NOT delete!!) additional data into the Exception object, as
> the stack is unwound.

But that's a plus. It means the approach scales up to any number of 
control flows, of which there are combinatorially many. Defining one 
type for each... well you wouldn't "like" that, either.

> By the time it gets to the final catch() block,
> you cannot guarantee a particular field you depend on will be defined.

Indeed. If you depend on anything you'd want to catch the specific type.

> Say if your call graph looks something like this:
>
> 	main()
> 	  +--func1()
> 	      +--func2()
> 	      |   +--helperFunc()
> 	      |   +--func3()
> 	      |       +--helperFunc()
> 	      +--func4()
> 	          +--helperFunc()
>
> Suppose helperFunc() throws HelperException, which func1's catch block
> specifically wants to handle. Suppose func2() adds an attribute called
> "lineNumber" to its catch block, which then rethrows the exception, and
> func3() adds an attribute called "colNumber".
>
> Now how should you write func1()'s catch block? You will get all
> HelperException's thrown, but you've no idea from which part of the call
> graph it originates.
> If it comes from func3(), then you have both
> "lineNumber" and "colNumber". If it comes before you reach func3(), then
> only "lineNumber" is defined. If it comes from func4(), then neither is
> present.

Exactly. So you suggest adding one type for each possible control flow? 
Are you sure this scales beyond a toy example?

> So your catch block degenerates into a morass of if-then-else
> conditions.

No, precisely on the contrary. You catch blockS degenerate into a morass 
of catch (This) { ... } catch (That) { ... } catch (TheOther) { ... }. 
That is fine if the code in different "..." does very different things, 
but it's a terrible approach if all do the same thing, such as 
formatting. That shouldn't make anyone feel better than using a morass 
of if/else.

The code with Variant[string] does not need combinatorial testing if it 
wants to do a uniform action (such as formatting). It handles formatting 
uniformly, and if it wants to look for one particular field it inserts a 
test.

> And then what do you do if you're depending on a particular
> field to be set, but it's not? Rethrow the exception? Then you have the
> stack trace reset problem.

Don't forget that Variant[string] does not preclude distinct exception 
types. It's not one or the other.

> Whereas if HelperException always has the the same fields, the catch
> block is very straightforward: just catch HelperException, and you are
> guaranteed you have all the info you need.

HelperException can definitely be there. It can only help if there's 
additional information associated with it.

> Then if func3() wants to add more info, create a new exception derived
> from HelperException, and add the field there. Then in func1(), add a
> new catch block that catches the new exception, and makes use of the new
> field.

They call that non-scalable code bloat.

> This does introduce a lot of little exception classes, which you could
> argue is class bloat, but I don't see how the Variant[string] method is
> necessarily superior. It comes with its own set of (IMHO quite nasty)
> problems.

Variant[string] is not superior because it doesn't compete against 
anything. It's a simple addition to the primitives available to the base 
Exception class.


Andrei