At 08:01 PM 8/18/00 -0600, Tony Olekshy wrote:
>RFC 88 is discussing making errors into exceptions. I strongly
>don't think we should attempt the converse, that is, making
>exceptions into errors.
>
> "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.
>That's why RFC 88 defines both Exception and Error classes, the
>latter of which inherits from the former. Common usage will be
>via Error, while still allowing for other non-error kinds of
>exceptions.
>
>Here at work we have algorithms that depend on throwing a
>rather large number of light-weight exceptions for the purpose
>of indicating exceptions that are not errors, but are non-local
>flow-control success gotos for an MVC architecture. The cost
>of capturing the stack traceback (for example) for every such
>exception would be prohibitive to us.
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? If the cost of capturing the stack
traceback were small would you change your mind?
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. If
stack traceback capture is expensive for a user module in Perl 5 that
doesn't mean it has to be in a core functionality in Perl 6.
--
Peter Scott
Pacific Systems Design Technologies
