At 09:40 PM 8/18/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > "An exception is not necessarily an error.\n" x 3;
> >
> > Note that 'error' is a vague term for which you have a specific
> > meaning in mind here; be sure to give that definition where it's
> > important.
>
>How 'bout something like, "an exception raised to signal an
>assertion failure that typically indicates the inability of
>an algorithm to complete the request it has been given".
>
> > >Here at work we have algorithms that depend on throwing a
> > >rather large number of light-weight exceptions [...]
> >
> > Is this the only reason for not making a single hierarchy
> > under Exception? So the core would use the subclasses
> > proposed in RFC 80 and users would use everything else?
>
>That's not what's proposed. The core and other users would use
>classes derived from Error to raise errors. Other users could
>even just Error itself. Exception is reserved for exceptions
>that don't and shouldn't derive from Error.
I'm still having a hard time with this. Maybe everyone else sees it and
can explain it to me. All I see is, you have a mechanism for implementing
non-local flow control. The reason the control flow skipped is surely
opaque and irrelevant to the mechanism? What the program decides to do
with that exception, likewise. Success and failure are more or less
arbitrary interpretations we place on these exceptions.
Aside from wanting the stack traceback in 'error's only (which I think is
improbable, it has to be implemented in the core anyway and it would
certainly be simpler to do it in the base class), I still don't see why you
need a separate thing you call an Error. To me, it's just an Exception
with a particular interpretation placed on it by the thrower and the
handler. Maybe not even that.
> > If the cost of capturing the stack traceback were small would
> > you change your mind?
>
>No. I want Error to be able to be extended, over the evolution
>of Perl 6, to include anything that is deemed suitable for
>error handling. I don't want any of that to interfer with
>base Exception functionality.
>
> > I ask because I think it would be confusing to have exceptions
> > which don't have that behavior. Conversely, that it would be
> > easier for the user to comprehend a model where there was only
> > one base class to understand.
>
>I think one of the biggest problems is people who confuse errors
>and exceptions,
That would be me :-)
> and making only one class is going to encourage
>them. For example, return code signalling will remain a valid
>error handling mechanism, for those subroutines that use it, and
>yet exceptions aren't involved.
But that's orthogonal to the issue of whether the base class should be the
same. Making the classes separate doesn't give the user a way to turn core
exceptions into return codes, or vice-versa.
Or does it? If this is what you're getting at, can you spell out what sort
of mechanism you have in mind please? I still have RFC 70 at the back of
my mind.
--
Peter Scott
Pacific Systems Design Technologies
