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. Once we've got
that, the RFC 80 "overriding" is just more OO serendipity.
> 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, 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.
For me this is an architectural issue, not a pragmatic one.
Those classes should be factored, according to all that is well
and good ;-) However, I will add a note to the RFC pointing
out that those classes could be merged, with the effect of
simplifying the description of the mechanism slightly.
And, based on all your fine comments, I'll continue to try to
make the RFC as clear as possible on the motivation for the
details of its proposal, where relevant.
Yours, &c, Tony Olekshy
