On Sun Jan 28 19:30:33 2018, TIMB wrote:
Show quoted text> Thanks for the test case, and sorry for the delay replying.
> I think your example demonstrates what I said earlier, "Some methods
> might be called on a database handle but internally they create and
> use a statement handle, such as the select_* methods."
Show quoted text> "the DBI handle being used" means it'll be called with a database handle when the error occurred on a database handle, and called with a statement handle when the error occurred on a statement handle. Some methods might be called on a database handle but internally they create and use a statement handle, such as the select_* methods
Ok, I understand this. I think this really vague.
1) The package is named DBI. There is connect method, which returns database handle. So people may think that "DBI handle" referrs to handle of class DBI (under the hood that it's
not blessed to 'DBI', but it's internals already)
2) If clever people don't think that way and understand that "DBI handle being used" means "any kind of object, which is used internally by DBI class and subclasses, which can
be referred as "handle" in this documentation", then it still does not help, because to use that object (call method, ready properties etc) you should understand it's interface,
i.e. you should have exhausive list of classes, that can be used here.
I propose changing docs to:
===
The subroutine is called with three parameters: the error message string that RaiseError and PrintError would use,
handle being used (database handle or statement handle, depending of internal implementation of the method that failed), and the first value
being returned by the method that failed (typically undef).
===
