The Right Approach to Exceptions

[Jonathan M Davis]

On Tuesday, February 21, 2012 14:15:03 Andrei Alexandrescu wrote:
> I thought I was pushing the generics angle, and OO people explained it 
> to me that that was wrong.

You were just talking about applying OO policy to exceptions, which just 
doesn't make sense for most things, because they're just not polymorphic in 
terms of how they're handled.

> I'm sorry, I was unable to derive information from this post. It's a
> string of assertion without any backing.

Just look at exceptions. You catch them by type and then use that specific 
type. You don't generally operate on them via polymorphic functions. Derived 
classes usually hold more data but do not change the behavior of any existing 
functions. Rather, you look at the type of the exception and the values of the 
member variables in that concrete type to decide how to handle the exception 
based on that information. That's not particularly OO or polymorphic at all.

Yes, you can catch more generic exceptions instead of the concrete ones, but 
that doesn't generally mean that you end up calling virtual functions on the 
base class. Rather, it means that your code cares less about what exactly went 
wrong. You're still not likely to be calling a virtual function on the 
exception type, because exceptions carry information, not behavior.

The one major exception to this is toString. Having generic error message 
generating capabilities is useful. And not even that needs to be polymorphic. 
With Exception, the return value of toString is generated from the msg 
property which was passed in via its constructor. And toString isn't something 
that you normally override with Exception. Rather, it's the msg argument which 
changes. At minimum, if you do override toString, you need to call the base 
class' toString or you'll lose the stack trace. It's just not really designed 
with overriding in mind.

I really don't see how anyone can make much of an argument for exceptions 
being OO beyond the fact that they're objects given that handling them means 
doing the complete opposite of typical OO. With exceptions, it's how they're 
handled that changes from type to type, not their internal behavior, whereas 
OO focuses on changing the behavior of functions in derived classes. And with 
exceptions, you use the concrete types and not an abstract interface, whereas 
in OO, the idea is to use an abstract interface.

So, I don't see much point in trying to force OO principles on exceptions. 
Trying to treat them more generically with regard to generating error messages 
makes some sense, but that's about it. And that still isn't particularly OO - 
especially when the proposed solution is to use Variant[string] rather than to 
do something with toString. But if you want to change the message formatting 
at the catch point (just like all of the other exception behavior is generally 
done at the catch point), you can't do it with toString (at least, not without 
changing the internal state of the exception before calling toString). OO just 
doesn't fit.

- Jonathan M Davis