On Wednesday, November 26, 2003, at 12:29 PM, Larry Wall wrote:
If you contrast it with an explicit try block, sure, it looks better. But
that's not what I compare it with. I compare it with Perl 5's:
$opus.write_to_file($file) or die "Couldn't write to $file: $!";
That has some known problems with false positives, er, negatives, which Perl 6 addresses with things like:
$opus.write_to_file($file) err fail "Couldn't write to $file: $!";
But if we're going to talk about philosophy, we should talk about Perl's notion of not forcing people to escalate all the way to exceptions when a lesser form of undefinedness or falseness will do. Perl 6 doesn't back off from this. In fact, it takes it further by allowing you to return unthrown exceptions as "undef". And by providing a "fail" that either returns or throws the exception depending on the preferences of the caller.
Well, yes, hmm, har, but...
Speaking only for myself, my own (database-heavy) code already makes pretty extensive use of the differences between "false", "unknown/undefined/NULL", and "worthy of exception" -- all three of those conditions may exist at various times, and no two of them can reasonably be lumped together as being logically identical.
There are plenty of cases where a piece of data being "undefined" or "NULL" means something different from it being zero, for example -- and neither case represents an actual error condition. Just undefinedness. So, for those cases, I'm forced into using full-fledged exception handling.
So as an abstract example, I would consider these to be entirely different, but each of them to be useful:
foo(...) or blah(...);
foo(...) err blah(...);
foo(...) catch blah(...);I read the first one as executing blah() if the result of foo() is a false value; the second as executing blah() if the result is something with an undefined or NULL value; the third as executing blah() if an otherwise fatal condition arises during the execution of foo(). All three can be considered constructs useful for quick-n-dirty recovery from the corresponding -- but very different -- exceptional conditions.
If you want to promote a catch modifier to me, you'd better market it as a form of "or" rather than a form of "try". I could see a form of "err" that implies a try around its left argument and coerces any caught exception to an undef exception.
Yes, precisely that.
But that sounds like a philosophical decision to be made consistently by the calling module. like "use fatal" in reverse. So I think I'd rather see a pragma that does that to "err" instead of adding yet another keyword.
I would explicitly not want that, personally, for the above reasons; there are many circumstances in which I'd rather use "undefined" to mean "undefined", rather than "exceptional/error condition".
Again, tho, TMTOWTDI. It's hardly a crisis if it doesn't exist. It just seems like an obvious simplification of try/CATCH when only one statement is being wrapped.
MikeL
