I started getting test failures for Exception::Class::DBI on Perl 5.6 recently. The failures seem to be due to this test:
# For some reason, under perl < 5.8.0, $dbh->{Kids} returns a different value # inside the HandleError scope than it does outside that scope. So we're # checking for the perl version here to cover our butts on this test. This may # be fixed in the DBI soon. is( $err->kids, ($] < 5.008 ? 1 : 0), "Check kids" );
Was this fixed in the DBI? If so, in what version (I saw a change to CachedKids in 1.55 that looked close, but that's not the same as {kids}, is it?)?
You've not given me much to go on, but I'd guess it's related to the timing of when perl invokes the DESTROY method (which has changed between perl versions). In which case it may be mostly beyond the control of the DBI.
A small self-contained example that behaves differently between different DBI/Perl versions will buy you more of my time :)
On Fri, May 02, 2008 at 01:23:33PM -0700, David E. Wheeler wrote: > Howdy,
> I started getting test failures for Exception::Class::DBI on Perl 5.6 > recently. The failures seem to be due to this test:
> # For some reason, under perl < 5.8.0, $dbh->{Kids} returns a different > value > # inside the HandleError scope than it does outside that scope. So we're > # checking for the perl version here to cover our butts on this test. This > may > # be fixed in the DBI soon. > is( $err->kids, ($] < 5.008 ? 1 : 0), "Check kids" );
> Was this fixed in the DBI? If so, in what version (I saw a change to > CachedKids in 1.55 that looked close, but that's not the same as {kids}, is > it?)?
> You've not given me much to go on, but I'd guess it's related to the > timing of when perl invokes the DESTROY method (which has changed > between perl versions). In which case it may be mostly beyond the > control of the DBI.
> A small self-contained example that behaves differently between > different DBI/Perl versions will buy you more of my time :)
Sorry Tim, I was hoping that that would be enough to shake some neurons loose for an easy answer. Here is my original query about this issue:
Only now I'm seeing that test fail on 5.6.2. Is it possible that 5.6.2 destroys the handle by the type the do() is called? I don't see your comment in 07kids.t anymore.
On Fri, May 02, 2008 at 07:03:10PM -0700, David E. Wheeler wrote: > On May 2, 2008, at 15:24, Tim Bunce wrote:
>> You've not given me much to go on, but I'd guess it's related to the >> timing of when perl invokes the DESTROY method (which has changed >> between perl versions). In which case it may be mostly beyond the >> control of the DBI.
>> A small self-contained example that behaves differently between >> different DBI/Perl versions will buy you more of my time :)
> Sorry Tim, I was hoping that that would be enough to shake some neurons > loose for an easy answer. Here is my original query about this issue:
If you really need to capture the complete state at the time the error *is recorded* rather than the time its *checked for and thrown* then you could use HandleSetErr instead of HandleError:
Hrm. I guess it wasn't telling us much, since it's dependent on Perl versions, rather than the implementation of the DBI.
> If you really need to capture the complete state at the time the error > *is recorded* rather than the time its *checked for and thrown* then > you could use HandleSetErr instead of HandleError:
Interesting, I hadn't seen that. As for my uses, I just wanted to get my tests passing again. No one has complained about the state of the error information in Exception::Class::DBI, to my knowledge. So I think I'll leave it as-is.
