Note that ALL warnings are explicitly disabled and the program is no longer printing the error messages yet the strange messages remain. Also note that the program does reach the final print.
Those messages are fatal errors that just don't happen to kill the program here, since they happen inside an eval(). They are being trapped, but we are still being notified (incorrectly). If they were lines in a normal script, it would not run.
That looks like a bug to me. I just wanted to make sure I wasn't missing something before submitting it. What do others think?
:)
IIRC this was discussed and cussed about around 1997 in comp.lang.perl.misc...
At any rate -
perldoc -f eval
If there is a syntax error or runtime error, or a
"die" statement is executed, an undefined value is
returned by "eval", and $@ is set to the error
message. If there was no error, $@ is guaranteed to
be a null string. Beware that using "eval" neither
silences perl from printing warnings to STDERR, nor
does it stuff the text of warning messages into [EMAIL PROTECTED]
To do either of those, you have to use the
$SIG{__WARN__} facility, or turn off warnings inside
the BLOCK or EXPR using "no warnings 'all'". See
"warn", perlvar, warnings and perllexwarn.IIRC it was determined then that 'eval' focus was to allow testing of trappable events - without allowing the code (however crazy) to die.
The side effects are such that there are tests which lead one to believe X is a bug when in fact it is a mis-represented feature and should be documented as such.
Simply saying "if this were in the real code" has little meaning since we are, after all, testing with eval.
Not to be hard-headed but I just dont see this as an issue; I would . rather have established manageable chaos.
(Not that my vote means so much; this is just my .02) -Sx- =)
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
