Jonathan Scott Duff wrote:
>
> On Sun, Aug 13, 2000 at 07:27:47PM -0700, Peter Scott wrote:
> >
> > An error has text associated with it, but also a bunch of other
> > attributes.
>
> So it's a structured data type... where does OOP come into play?
1. It allows you to *extend* the base type with new attributes
without having to re-implement all the base attributes.
2. It allows you to *extend* the base type with new methods that
can, say, compute predicates based on the object's attributes.
Then, you can say things like:
if ( $@->isa(MyException) && $@->CanFoo ) { ... }
3. Is allows you to *override* base class behaviour, for example,
by changing the way stringification works for some classes, or
by modifying a constructor to do some sort of logging, for some
class of exceptions.
> > They fall naturally into different classes, some of which have
> > subclasses (a File error is-a IO error).
>
> This, to me, seems a mere matter of naming. Was it that OOP already
> had a hierarchical naming system and so it was used?
Once the other good reasons for OO exceptions come into play, you
may as well take advantage of the serendipity.
> What does it mean for an exception to have semantics? When an
> exception is thrown does something special happen whether it's
> caught or not?
$@->CanFoo is an example of semantics that determines whether or
not the exception is caught; stringification may be an example
of semantics that comes into play when an exception is caught.
Yours, &c, Tony Olekshy
