Closed p5pRT closed 20 years ago
------- Forwarded Message
Date: Mon\, 06 Sep 1999 04:51:55 GMT From: Rick Delaney \rick\.delaney@​home\.com Subject: Re: "use strict" errors are second-class exceptions? Organization: @Home Network Canada Newsgroups: comp.lang.perl.misc Article: 251674 of comp.lang.perl.misc X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.ab.home.com 936593515 24.65.44.96 (Sun\, 05 Sep 1999 21:51:55 P DT) NNTP-Posting-Date: Sun\, 05 Sep 1999 21:51:55 PDT
[posted & mailed]
Sean McAfee wrote:
perldiag classifies strictness violations in precisely the same category as other trappable errors which put errors into $@ when encountered inside an eval. In my admittedly not-totally-exhaustive perusal of the Perl docs\, I can't find any documented reason for this difference in behavior. Is this then a bug?
Could be. This has been mentioned here a couple of times before. Here's one of them
http://x46.deja.com/getdoc.xp?AN=483645444
I'm using Perl 5.005_03.
Man\, what a bummer. It's rather crucial for the code I'm writing now to be able to distinguish warnings from fatals.
I remember this trick from Mike Guy to check compilation with eval.
use strict; my $code = 'FOO; print "made it\n";'; eval "die 'Compiled OK';$code"; print "failed strict\n" if $@ !~ /Compiled OK/;
It could still have side effects if you have BEGIN or use in $code\, though. And you have to eval again if you actually want to run $code.
I'd at least like to see $@ =~ /eval had compilation errors/ when the code fails the strict test\, even if all the warnings couldn't be jammed in there.
- -- Rick Delaney rick.delaney@home.com
------- End of Forwarded Message
Witness this code:
# warntester use strict;
my($str\,$retval);
$^W = 0; # absolutely no warnings no warning; # ditto no warning "all"; # paranoia
# XXX: this "can't" happen $SIG{__WARN__} = sub { print "Leaked warning: @_\n" } ;
numout();
$str = q{ print $x }; $retval = eval $str;
if ($@) { print "eval #1 failed: $@\n" } printf "retval #1 is %s\n"\, defined($retval) ? ($retval ? "true" : "false") : "the undefined value";
$retval = eval $str; if ($@) { print "eval #2 failed: $@\n" } printf "retval #2 is %s\n"\, defined($retval) ? ($retval ? "true" : "false") : "the undefined value";
close STDOUT; exit;
sub numout {
my $kid = open(STDOUT\, "|-");
die "fork: $!" unless defined $kid;
return if $kid;
print "$.: $_" while \
That produces:
1: Leaked warning: Global symbol "$x" requires explicit package name at (eval 1) line 2. 2: 3: retval #1 is the undefined value 4: retval #2 is true
First of all\, that shouldn't be a warning when it's going to terminate the eval. Second of all\, the rule is anything that terminates an eval must set $@. This didn't. And no\, the print of undef didn't return undef\, because print defined(print undef) produces 1. Thirdly\, both retvals should produce the same value\, but don't. Fourthly\, the error is now forgotten about\, because of the attempt to suppress duplicates.
This makes it impossible to employ the important strict pragma for a certain class of problems. This is an important bug. I do not know how to fix it\, however\, because you don't want to terminate the attempt at compilation earlier than you really have to; otherwise\, you don't get as many errors out as once as possible. Nor do you get too many duplicates (yes\, the diagnostics pragma suppresses dups or semi-dups\, but the normal course of events doesn't.)
--tom
On Mon\, 06 Sep 1999 10:21:08 MDT\, Tom Christiansen wrote:
From: Rick Delaney \rick\.delaney@​home\.com Subject: Re: "use strict" errors are second-class exceptions?
[posted & mailed] [...] I remember this trick from Mike Guy to check compilation with eval.
use strict; my $code = 'FOO; print "made it\n";'; eval "die 'Compiled OK';$code"; print "failed strict\n" if $@ !~ /Compiled OK/;
It could still have side effects if you have BEGIN or use in $code\, though. And you have to eval again if you actually want to run $code.
I'd at least like to see $@ =~ /eval had compilation errors/ when the code fails the strict test\, even if all the warnings couldn't be jammed in there.
- -- Rick Delaney rick.delaney@home.com
------- End of Forwarded Message
Witness this code:
# warntester use strict;
my($str\,$retval);
$^W = 0; # absolutely no warnings no warning; # ditto no warning "all"; # paranoia
\# XXX​: this "can't" happen
$SIG{__WARN__} = sub { print "Leaked warning: @_\n" } ;
numout();
$str = q{ print $x }; $retval = eval $str;
if ($@) { print "eval #1 failed: $@\n" } printf "retval #1 is %s\n"\, defined($retval) ? ($retval ? "true" : "false") : "the undefined value";
$retval = eval $str; if ($@) { print "eval #2 failed: $@\n" } printf "retval #2 is %s\n"\, defined($retval) ? ($retval ? "true" : "false") : "the undefined value";
close STDOUT; exit;
sub numout { my $kid = open(STDOUT\, "|-"); die "fork: $!" unless defined $kid; return if $kid; print "$.: $_" while \
; exit; } That produces:
1: Leaked warning: Global symbol "$x" requires explicit package name at (eval 1) line 2. 2: 3: retval #1 is the undefined value 4: retval #2 is true
First of all\, that shouldn't be a warning when it's going to terminate the eval. Second of all\, the rule is anything that terminates an eval must set $@. This didn't. And no\, the print of undef didn't return undef\, because print defined(print undef) produces 1. Thirdly\, both retvals should produce the same value\, but don't. Fourthly\, the error is now forgotten about\, because of the attempt to suppress duplicates.
This makes it impossible to employ the important strict pragma for a certain class of problems. This is an important bug. I do not know how to fix it\, however\, because you don't want to terminate the attempt at compilation earlier than you really have to; otherwise\, you don't get as many errors out as once as possible. Nor do you get too many duplicates (yes\, the diagnostics pragma suppresses dups or semi-dups\, but the normal course of events doesn't.)
Thanks for that test case. I think this patch addresses everything you've identified.
Sarathy gsar@activestate.com
Migrated from rt.perl.org#1321 (status was 'resolved')
Searchable as RT1321$