On Sat, May 07, 2011 at 03:45:02PM +1000, Michael G Schwern wrote: > I was just playing around with eval, trying to figure out if you can define an > operator overload at runtime (seems you can't, good) and noticed this in the > spec... [1] > > "Returns whatever $code returns, or fails." > > How does one get the compile error from an eval? What's the equivalent to $@? > I don't see anything in the eval tests [2] that's checking for the error, > just that it returned false.
The error goes into $!, which is automatically lexical.
What you're seeing is a bug-of-omission in Rakudo; if $! is not checked by
the end of the scope, Perl 6 is supposed to raise an immediate exception.
> In addition, I'm surprised that eval doesn't throw an error when it fails.
>
> try { eval $code; CATCH { ... } }
>
> Using eval STRING in Perl 5 is pretty rare, and should hopefully be rarer in
> Perl 6 than Perl 5. While it can be used as a "does this compile" check, it's
> overwhelmingly used with the expectation that the code will compile and so it
> is an exception if it does not. More pragmatically, this resolves the problem
> of $@ by putting it into an exception rather than a side global.
>
> It also resolves this trap:
>
> if eval $code {
> say "code returned true";
> }
> else {
> # this will also happen if $code fails to compile
> say "code returned false";
> }
>
> While Perl 6 probably has some sort of magic "I failed" value you can check
> for separate from boolean false, folks aren't going to go through the extra
> convolutions.
Larry doesn't like immediate exceptions very much, citing something about
"parallel processing". fail() is much preferred for stuff in the specs.
-Stefan
signature.asc
Description: Digital signature
