On Sep 30, 9:07 pm, jon.herman...@gmail.com (Jon Hermansen) wrote:
rg/>
>
> ...
>
> Thanks for the help. I was able to find a few workarounds with your
> examples. I found something interesting in my testing-- at the end of my
> sub, if instead of:
>
> return 1 unless ($@);
>
>
> I use:
>
> if (not $@) {return 1;}
>
>
>
> OR
>
> return 1 if (not $@);
>
>
>
> the syntax error does not get printed out. I assumed that these statements
> were logically equal, so, what gives?
I'm not sure. As Ruud mentioned, the return value of
the eval -- rather than $@ -- is the key. If, for instance,
you still are using a __DIE__ handler and aren't careful,
it could potentially wipe out the original $@ message:
$ret = eval {
local $SIG{__DIE__} = sub { ... ; die;};
... # parse error here and $@ gets set
1;
};
Now, however, $@ could be empty even though the eval {}
failed with a parse error. See: perldoc -f eval for more
explanation.
So, you'd need to post some more code to determine what
went wrong.
--
Charles DeRykus
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
