I intend to change the definition of "eval" such that it does not catch exceptions. String eval's role as the catcher of exceptions is a legacy of Perl 1, which had no block eval, and I feel it has no place in Perl 6.
The exception catching and associated unwinding makes it impossible to use resumable exceptions across eval boundaries. This includes warn. Given an eval that does not catch exceptions, it is very easy to add catching, using the new blockless form of try, "try eval $code". However, given an eval which does catch, it is impossible to synthesize one that passes exceptions faithfully. Catching exceptions in an eval causes the eval frame to be different from the calling frame, which makes tail call optimization through evals impossible. With the catching eval, it is very easy to write code which accidentally discards exceptions. For the goal of safety it seems best to make discarding exceptions hard by default. Does anyone have objections? Is there general consensus that this change should be made? -Stefan
diff --git a/S29-functions.pod b/S29-functions.pod index 21a0cc4..9459036 100644 --- a/S29-functions.pod +++ b/S29-functions.pod @@ -226,7 +226,9 @@ for C<$lang> would usually do to input files. The default for C<$lang> is the language in effect at the exact location of the eval call. -Returns whatever C<$code> returns, or fails. +Returns whatever C<$code> returns. If C<$code> generates an exception, +that exception will be propagated, unlike Perl 5. Use "try eval" if +you want to catch exceptions. =item evalfile
signature.asc
Description: Digital signature
