2000-08-10-11:52:31 Dan Sugalski:
> Why not, then, introduce non-fatal errors and a new keyword to
> throw them?
If we were to add a non-fatal exception type, that would just mean
that those of us who want errors to behave differently than they do
now, would have to wrap our whole program in a catcher; that's just
a couple of extra lines of clutter, and I'm sure they could be
deposited in a module to reduce it back to the desired one line.
Arranging for all the builtins to throw a non-fatal exception would
impose a cost on the rest of the folks, who prefer to have most
errors ignored (the way perl currently works), but who want to just
check for the error return from select calls: they would have to do
things differently.
Your suggestion (all builtins through non-fatal exceptions for error
reporting) would make implementing Fatal.pm a lot easier, but a less
intrusive measure (making all error-reporting buitins wrappable, my
RFC 70) would at least make Fatal.pm possible to implement
completely, and would inflict little or no change on the people who
like perl's currently style of error reporting.
But I do see one worry about the proposed non-fatal exception type,
and that is that it would require some interesting implementation
hair to make it work; unlike the current exceptions, non-fatals
would require passing state downward, and defining its scope,
because the routine throwing an exception has to know whether
they're being caught before it actually throws. Or else we'd have
to have continuations, and the non-fatal exception could be thrown
with a continuation, which a default catcher could use to resume
execution ignoring the error. I can't believe I suggested that.
-Bennett
PGP signature
