* Glenn Golden <gdg@zplane.com> [2015-05-11 23:25]: > Regarding this example from perlfunc.pod, pertaining to "do": > > =================================================================== > for $file ("/share/prog/defaults.rc", "$ENV{HOME}/.someprogrc") > { > unless ($return = do $file) { > warn "couldn't parse $file: $@" if $@; > warn "couldn't do $file: $!" unless defined $return; > warn "couldn't run $file" unless $return; > } > } > =================================================================== Wow, that’s bad. > Is the final "unless $return" necessary? No. > Also: The meaning of the word 'run' in the warning text "couldn't run > $file" seems unclear. If my understanding of the accompanying doc text > is correct, seems like it should be possible to reach that warning > clause only if the final expression resulting from evaluating $file is > false. If this reading is correct, would it make sense to change the > warning text to something more directly interpretable by the reader, > e.g. "final expression evaluating $file is false"? As far as the example goes, that would work. The apparent intent might be better expressed by "invalid configuration returned from $file". But the example doesn’t make much sense. You can write a “configuration” file whose final expression yields undef and confuse it; as well, under several conditions it will display several warnings for the same file. I *think* this untested code covers all the bases… for my $file ("/share/prog/defaults.rc", "$ENV{HOME}/.someprogrc") { local ($!, $@); $return = do $file or warn ( $@ ? "couldn't parse $file: $@" : $! && !defined $return ? "couldn't do $file: $!" : "invalid configuration returned from $file" ); } … but I’m not sure about $! and there may not be any unambiguous signal for that case available. Also, $@ being set doesn’t point to a parsing error specifically – just an exception thrown at any point before the code in the file returned. So that message is wrong. In short… that is one terrible example. > If so, I'll be happy to submit a doc patch for either/both of these > changes, but wanted to first ask if my understanding of this was even > correct. It doesn’t make sense to me to promote `do` as a configuration loader mechanism in the first place, not even in trying to contrive a use case for `do`. I’d go with a narrowly focused example, dumping the loop and rewording the error messages to purely problem-domain statements that describe each error condition precisely. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next