Re: ada paper critic

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Jeffrey Carter <jrcarter@acm.org> writes:

> This seems to be an incomplete sentence. If I interpret it correctly,
> the Ada intent is that the information be carried primarily by the
> exception name. You should not be using a single exception and
> differentiating between logical exceptions by the information attached
> to that exception.

The problem with this view is that it forces the designer of an
abstraction to decide on the granularity of exception handling, when
this decision rightly belongs in the hands of the person designing the
*handler*.  In fact, different handlers have different requirements:
e.g., one handler might want to handle all I/O errors, whereas another
one might want to handle disk_full_error specially.  If the designer of
the abstraction decided to lump all I/O errors under one exception name,
then the fine-grained handler is impossible to write.  On the other
hand, if the designer of the abstraction defined many exceptions for
different kinds of I/O errors, then the coarse-grained handler has to
mention them all, which is overly verbose, and unmaintainable, because
there might be a new kind of I/O error invented tomorrow.

So the designer of the abstraction is forced into a poor design for
*some* possible clients.  This is not good for reusability.

In many other languages, this problem does not occur, because exceptions
are defined hierarchically.

> Also, exceptions should only be used for exceptional situations, so this
> does not impact normal processing at all.

I don't see how that's relevant.  A bug in exception handling is a bug,
even though exceptions occur only rarely.  (In fact, *all* bugs are rare
-- if the thing crashes within seconds most of the time you run it, the
programmer will notice it and fix it.)

- Bob