HaloO,
Larry Wall wrote:
My gut-level feeling on this is that $! is going to end up being an
"env" variable like $_.
I just re-read about exceptions. Well, I undestand now that $! is
intented as a variable with a spectrum of meanings ranging from
1) the return value of a sub, through
2) an error return value, up to
3) a non-return value.
Of these only the last is what I know as exceptions. I'm for now
undecided to regard these three purposes of $! as very clever or
as big potential for subtle problems. From the viewpoint of the
execution model this environment approach is very clear, though.
It nicely unifies return values with in-band errors and out-band
exceptions. Which leaves just one wish from my side: make CATCH
blocks dispatched. That is they get a signature what kind of
exception they handle. The optimizer will make good use of this
information.
Then the problem reduces
to what you do with an unhandled $! at the end of a lexical scope,
I don't understand this. The end of scope is either the closing
brace or an explicit statement like next, leave, return, yield,
fail or die. In the above spectrum of $! these are resultizer
just as given, for and friends are topicalizer for $_. But I think
simple assignment to $! is not foreseen, or is it?
For an example let's assume that / returns 'undef but division by zero'
in $! if its rhs is zero.
{ # begin of scope
my $x = 3;
my $y = 4;
say $x/$y;
$x = foo; # foo could return 0
my $z = $y/$x; # $! == 'undef but division by zero' if $x == 0
# Is that assignable to $z?
$z++; # This is now a statement in a potential CATCH block?
}
--
$TSa.greeting := "HaloO"; # mind the echo!
