[prev in list] [next in list] [prev in thread] [next in thread] 

List:       msql-mysql-modules
Subject:    Re: Intercepting DBD:ODBC errors
From:       zzapper <david () tvis ! co ! uk>
Date:       2005-04-14 15:04:49
Message-ID: 0d1t515sf21132memhbks0d87alv5jckpp () 4ax ! com
[Download RAW message or body]

On Mon, 11 Apr 2005 13:37:46 -0400,  wrote:

>On Mon, 2005-04-11 at 18:00 +0100, zzapper wrote:
>> On Mon, 11 Apr 2005 12:45:51 -0400,  wrote:
>> >On Mon, 2005-04-11 at 16:57 +0100, zzapper wrote:
>
>[snip]
>
>> >    By default, "DBI->connect" sets "PrintError" "on".
>
>> Whoops I also had it specifically switched on, but what's the best
>> policy have it on for testing OR leave it off and always test at the
>> Perl level?
>
>I don't know.
>
>I usually specify RaiseError => 1, PrintError => 0.  I also wrap queries
>that I expect can fail in eval { ... }, if I want to process the
>failure.  Otherwise, the default behavior is fine.  (The exception is
>not caught and results in a message on stderr and non-zero exit() code.)

Gary 
My experiences
You must set raiseerror otherwise hangs or reports no errors

The only way I could intercept the errors was with eval (thanx)

eval {$sel = $db->prepare($sql); $sel->execute};
&fn_error_handler($sql) if $@;

BTW watch out for eval as it changes data scoping!!!

Cheers!!



-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:    http://lists.mysql.com/perl?unsub=msql-mysql-modules@progressive-comp.com

[prev in list] [next in list] [prev in thread] [next in thread]