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!

Reply via email to