I agree with the change. Let "try" be for exceptions and "eval" be for runtime
compile+run of code. These are very distinct concepts and should be separate.
-- Darren Duncan
Stefan O'Rear wrote:
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
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?