in reply to Silencing the grumbling from DBD::ODBC

I would need to experiment a bit before I would know for sure, but if your eval were merely dying, I would expect the error to be in $@. Warnings, however, I'm not sure. Perhaps you should try trapping them with $SIG{__WARN__}?
Note: Code samples are for conceptual use only and generally are not meant to be cut/pasted into a production application. Always 'use strict', have a thorough understanding of the code you use, and check the return values of functions and handle errors according to your needs. - Fastolfe

Replies are listed 'Best First'.
RE: Re: Silencing the grumbling from DBD::ODBC
by little (Curate) on Sep 28, 2000 at 19:32 UTC
    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
[reply]
[d/l]
      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]

In Section Seekers of Perl Wisdom