Re: Eval Errors

From: R. Joseph Newton (rjnewton_at_efn.org)
Date: 02/24/04


Date: Tue, 24 Feb 2004 09:28:22 -0800
To: sx@insecurity.org

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 $@.
> 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



Relevant Pages

  • Re: Eval Errors
    ... > longer printing the error messages yet the strange messages remain. ... IIRC it was determined then that 'eval' focus was to allow testing of ... X is a bug when in fact it is a mis-represented feature and should be ... Simply saying "if this were in the real code" has little meaning since ...
    (perl.beginners)
  • Re: Advice needed: threads and queues
    ... use warnings; ... This will give you some additional error messages that you should fix. ... It's not a bug, it's the future. ...
    (comp.lang.perl.misc)
  • Re: [PATCH -mm] sys_semctl gcc 4.1 warning fix
    ... I disagree here that it covers up any bug. ... In fact, that wrapper is more ... So if you like to look for real warnings, you can compile it with the ... and have to fight to find the real bugs. ...
    (Linux-Kernel)
  • Re: changed queries save automatically
    ... Not exactly a "tiny" bug is it? ... A query not prompting you about saving it is one of the symptoms of this ... macro or code someone has Set Warnings to Off but forgot to Set ... Compacting and repairing closes the database and reopens it. ...
    (microsoft.public.access.queries)
  • Re: A toughy.
    ... Do I ignore all those warnings and using add and remove just delete the darned thing? ... I have always used HTML for my personal posts and the HTML doesn't seem to ... Bug 2. ... Paying users do not have this message in their emails. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)