On Sun, Mar 23, 2008 at 01:28:06AM -0400, Mark J. Reed wrote:
: On Sat, Mar 22, 2008 at 8:00 PM, Aristotle Pagaltzis [EMAIL PROTECTED]
wrote:
: What does Perl 6 do in that respect? Maybe semantics could be
: borrowed from there?
:
: In which respect?
:
: TTBOMK, both eval's role as pseudo-try and the $@ variable are gone
: in Perl6, which has a real try instead. If the eval'ed code fails,
: the eval itself just fails right along with it; so there's no need for
: a split along the lines of $! vs [EMAIL PROTECTED]
Actually, we haven't gone that far with eval-string yet. It still traps
errors, but puts them into $!, which now holds all exception values. $@
and $? and $^E are all gone.
The main difference semantically is that $! is always a lexically scoped
variable, and when you call a function and it fails, the failure code is
authorized to set its parent's $!, which happens to be your $!.
We also distinguish die (which always throws an exception) from fail
(which only throws an exception under use fatal, and otherwise
returns an unthrown exception, which is an interesting value
of undef). Unthrown exceptions are an important way forward into
parallel programming. You really can't afford to have the vector
operations on your rocket blowing up (literally, in this case) merely
because one of your sensors is reporting an impossible 0 value.
Of couse, if you try to use such an unthrown exception as an actual
value, then the exception gets thrown for real. (But it has all
the original exception info in it, so you can still figure out why
the rocket blew up, hopefully, assuming your rocket is smart enough
to transmit the exception info before it triggers a self-destruct.)
Another important semantic difference is that exception handlers are
run before the stack is unwound, not after. This has to big benefits.
An exception handler can turn a fatal exception into a mere warning
and continue. But the bigger win is that this unifies warnings with
exceptions with warnings, so the dynamic scope handles both the same
way, and can also go the other way and turn a warning into a fatal
exception. A warning is simply an exception that is expected to
resume, but might not.
Another divergence from Perl 5 is that you can turn any block into
a try block merely by putting a CATCH block inside it. And the
exception handlers within a CATCH are merely a switch statement where
the topic is $!. No special exception matching syntax--I'm too lazy
for that. :)
The other aspects of exception handling in Perl 6 are discussed in
http://perlcabal.org/syn/S04.html
if you're interested. (Or even if you're not...)
Anyway, a lot of these design changes work together to produce a
smoother result. I confess I haven't thought much about whether they
could be borrowed piecemeal; I have a hard enough time keeping one
fanatasy language in my head at a time. :)
One place we have not yet completed the Perl 6 design is to create
a hierarchy of exception object types. We're kinda waiting to
see what the various implementations need on that, but if anyone
wants to contribute, a preliminary design of that would be useful.
Probably even a discussion of the current state of the art in Perl 5
would be useful there.
[Note, this is intentionally cross-posted, so please be careful with
your followups if they would be of interest to only one list or
the other.]
Larry
