The Right Approach to Exceptions
Jonathan M Davis
jmdavisProg at gmx.com
Tue Feb 21 16:43:32 PST 2012
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
More information about the Digitalmars-d
mailing list