On Wed, Oct 04, 2006 at 10:35:05AM -0400, Aaron Sherman wrote:
: Damian Conway wrote:
:
: > @bar».foo if $baz;
:
: That brought to mind the question that I've had for some time: how are
: exceptions going to work on hyper-operators?
:
: Will they kill the hyperoperation in-progress? e.g. what will $i be:
:
: my $i = 0;
: class A { method inci() { die if $i++ > 5 } }
: my Array of A @aoa;
: try { @aoa>>.inci; }
: say $i;
:
: Is it even possible to know, or is it entirely dependent on the
: implementation? And what do multiple, successive dies within the same
: try block do?
An uncaught exception is going to blow you out of the hyperoperator
when it's partway done, just like any other operator. Since a
hyperoperator is a promise that you don't care about ordering of side
effects, any code that relies on a particular implementation's ordering
of side effects is erroneous.
Which is all an excellent argument for unthrown exceptions being
the norm. Then the hyper can proceed to completion and you just
have to be careful how you use the resulting undefined values.
For hypers that must produce unboxed native types, you don't have
the undef option, but at least IEEE floaters give you NaN and Inf.
This also tells me that we'll occasionally want to turn normally fatal
exceptions into unthrown exceptions. Fortunately, Perl 6 specifies
that CATCH blocks run before the stack is unwound, so this should be
possible in theory. Of course, this is not guaranteed to work unless
the undef value is returned immediately to the hyperoperator manager,
since the called code may not have anticipated that it might have to
continue with an undefined value.
All the more reason to encourage use of "fail" rather than "die".
Larry
