On Nov 14, 2013, at 7:57 AM, David E. Wheeler <da...@justatheory.com> wrote:
> Yep, I am using 1.628.
>
> I'm wondering, though, if callbacks should not be considered internal calls,
> and the "outer" handle passed to them?
So the output with 6.30 is:
connected
done connectiong
DBD::SQLite::db connected failed: no such table: foo at
/usr/local/lib/perl5/site_perl/5.18.1/darwin-thread-multi-2level/DBI.pm line
733.
Which feels weird. Ideally, with do() causing an error, I would normally expect
"done connectiong" not to be emitted. Ideally, do() should raise an error and
nothing further in the callback should execute. When stuff does execute, it
means that the original error can be obscured.
For example, I changed the callback to:
say 'connected';
$_[0]->do('SELECT 1 from foo');
$_[0]->do('SELECT 1 from bar');
say 'done connectiong';
And the output is now:
connected
done connectiong
DBD::SQLite::db connected failed: no such table: bar at
/usr/local/lib/perl5/site_perl/5.18.1/darwin-thread-multi-2level/DBI.pm line
733.
The error about "foo" not existing is gone, overridden by the second error
about "bar" missing. This can lead to hard-to-find bugs. What if the second
query depended on a condition set up by the first, and the first failed? As a
user, I would only see the second error, and think that the first statement had
succeeded. It would take me quite a while to figure out that it had not, in
fact, succeeded.
All of which is to say, your fix in 1.630 certainly improves the situation, but
since callbacks are really userland code, I think it would be beneficial to
change callbacks to run in an outer context, with the outer DBI handles passed
to them. Possible?
Thanks,
David
