Hi,
Certain types of mysql error seem to directly output their error message and thus break break my
scripts before the error can be intercepted at the perl level and dealt with gracefully.
Ideas?
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
On Mon, 2005-04-11 at 16:57 +0100, zzapper wrote:
> Certain types of mysql error seem to directly output their error message and thus break break my
> scripts before the error can be intercepted at the perl level and dealt with gracefully.
>
> Ideas?
I guess you mean the DBI module(?). See the DBI(3) manual page,
PrintError in the ATTRIBUTES COMMON TO ALL HANDLES section:
By default, "DBI->connect" sets "PrintError" "on".
--
Garry Williams, +1 678 565-4579
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
On Mon, 11 Apr 2005 12:45:51 -0400, wrote:
>On Mon, 2005-04-11 at 16:57 +0100, zzapper wrote:
>> Certain types of mysql error seem to directly output their error message and thus break break my
>> scripts before the error can be intercepted at the perl level and dealt with gracefully.
>>
>> Ideas?
>
>I guess you mean the DBI module(?). See the DBI(3) manual page,
>PrintError in the ATTRIBUTES COMMON TO ALL HANDLES section:
>
> By default, "DBI->connect" sets "PrintError" "on".
>
>--
>Garry Williams, +1 678 565-4579
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?
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
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.)
--
Garry Williams, +1 678 565-4579
--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org
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=gcdmp-msql-mysql-modules@m .gmane.org