in reply to Re: Silencing the grumbling from DBD::ODBC
in thread Silencing the grumbling from DBD::ODBC

right, I agree,
but the assignement of the query result to the variable happens, before that variable gets evaluated. And he is not looking for the result of the eval as he would do by saying : 
      $ref = eval{$dbh_g->selectcol_arrayref($sql)};

[download]
??
Have a nice day
All decision is left to your taste

Replies are listed 'Best First'.
RE: RE: Re: Silencing the grumbling from DBD::ODBC
by Fastolfe (Vicar) on Sep 28, 2000 at 19:37 UTC
    They are equivalent. Consider: 
    $a = $b = 0;

eval { $a = 3; };
$b = eval { 3; };

print "$a, $b\n";    # 3, 3

    [download]
    Eval operates in the same context as any other code. The return from eval is the return value of whatever that eval did. The only difference is that eval blocks can't die; errors are stored in $@ and execution of the eval block stops.
[reply]
[d/l]
[select]
      $a = 'die "whohoo";';
$b = 3;
print "mmh".eval($a)."?";
print "mmh".eval($b)."?";

      [download]
      Have a nice day
      All decision is left to your taste
[reply]
[d/l]
        Perhaps I'm missing something, but shouldn't the returned value here be undefined? He's testing $ret. If the eval failed (died, whatever), $ret should be undefined. His test should work.

        I think the problem though is that the eval isn't dying. It's just warning. $ret thus is set to the return of whatever the fetch method he used. If his eval died, we shouldn't see an error message at all, it should go into $@.

        Sorry if I'm missing something or if we're talking about two slightly different things.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom