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

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.

Replies are listed 'Best First'.
RE: RE: RE: RE: RE: Re: Silencing the grumbling from DBD::ODBC
by little (Curate) on Sep 28, 2000 at 19:59 UTC
    No,
    cause the result of the query is the warning, which is a string, so the eval gives back a string and does not die, cause it has not interpreted the query but the query result.
    Have a nice day
    All decision is left to your taste
      If things are as you say they are, I would consider that a bug with DBI. A method should never, upon failure, simply return the error message in a string. That makes true/false type tests impossible. If I am writing a method that fails, I might print out a warning via warn, sure, but I would ALWAYS return a false value from that method so that people using my code can test for success/failure based upon that. That is very brain-dead if (as you seem to indicate), DBI is returning a string where ordinarily we would see an array reference or a boolean true/false indication.

      If the method under normal circumstances is returning a false value, and correctly printing its warnings via warn, this is not touched by eval:

      $a = eval { warn "some warning\n"; }; # "some warning" to STDERR print "a=$a\n"; # 1 ('warn' succeeds) print "@=$@\n"; # <undefined>
      We have to trap $SIG{__WARN__} if we want to capture the "some warning" text. Otherwise it's printed straight to STDERR, even if we're in an eval block. Eval doesn't "return" the warning, it returns whatever its code returns (in this case, whatever selectcol_arrayref returns). I think you're mistaken.