NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
storm of protest (Score:1)
Not a fan of this change. What's wrong with saying
$foo->require or die $@;That's not too much to type. It breaks this kind of useful idiom:$this->require or $that->require or die "No alternatives found: $@";and it breaks this kind of portability even moreIt also makes it difficult to write a custom error message - I have to wrap the call in an eval, and so we're back where we starte
Re:storm of protest (Score:2)
Error checking should be something you turn off, not something you turn on. Especially when it comes to dealing with the World Outside Your Program. Files, networks, etc... things not totally under your program's control and thus likely to do unexpected things.
I will say using $@ to return the error is a lot better than $UNIVERSAL::require::ERROR, and it seems to work... which is an accident, but a happy one. It certainly makes me gag a lot less. However I'm not happy about the mixing of idioms, using $@ for an error even though there's no (visible) eval.I have no matching idiom for that and that bothers me. Though it bothers me less than thinking about having to append "or die $@" on the end of most of my require calls much in the same way it bugs me about open() or any other "outside world" call. I tend to
use Fatala lot.That makeseval { $foo->require } or do_bleha little difficult.Its a little known, and little used, fact that you can return pretty much any scalar from require including references.
Reply to This
Parent