The Right Approach to Exceptions

[H. S. Teoh]

On Sun, Feb 19, 2012 at 02:04:50AM -0600, Andrei Alexandrescu wrote:
> On 2/19/12 12:56 AM, Jonathan M Davis wrote:
> >I think that being able to have a catch block which took multiple
> >exception types would be plenty. There are times when it would be
> >very valuable to be able to use the same catch block for multiple
> >exceptions without having to catch their base type (which would then
> >potentially catch other exceptions which you didn't want to catch).
> >So, something like that second catch block that you have there would
> >be very valuable.
> 
> So now hierarchies are not good?
[...]

It's not a simple black-or-white decision we're dealing with here. :)

Although exception hierarchies are currently the best we have, it's not
perfect, and it does have its own flaws. If we can figure out a better
system that fixes those flaws without compromising the good points of
using a class hierarchy, that would be even better.

The core of the problem is this: when an exception happens, it's within
a specific context with the associated domain-specific data. This
context and domain-specific data can be totally disparate types.

For example, a FileNotFound exception occurs in the filesystem, and is
associated with a filename. A SeekError also occurs in the filesystem,
is associated with a file (not necessarily equivalent to a filename),
and a seek offset. By contrast, a NetworkTimeout error happens in the
network stack, is associated with a particular protocol (say TCP), a
particular network socket (with its own associated IP address, etc.),
and a particular timeout value. It has no associated filename, or seek
offset.

So you have a bunch of exceptions, each of which is associated with a
bunch of info that, in general, have no relation with any info
associated with another exception. The problem at hand is: how do you
represent this info in a useful way? Generally speaking, the only common
thing between all exceptions is the fact that they are, well,
exceptions. And some of them are more closely related to each other than
others -- file-related exceptions may, for example, share the fact that
they are tied to a specific file.

To me, this is a giant hint that OOP is a good solution. You want a
class hierarchy rooted at Exception. And groups of related exceptions
probably should be rooted under their respective base classes under
Exception.

If you have a better way to solve this, I'm waiting to hear it.


T

-- 
Gone Chopin. Bach in a minuet.