WC -Sx- Jones wrote:
> James Edward Gray II wrote:
> > 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- =)
I agree. This actually seems like perfectly appropriate behavior for eval. The
puprose of the function is, after all, to evaluate code--to get information
about its effects and output value when run. What warnings a piece of code
raises is certainly a very useful part of the overall information.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
