Library using PDO object - php

Question

I'm writing a library which requires a database connection, so it requires users to pass a PDO object as a parameter of the constructor.
But as many of you know, PDO has 3 different error reporting mechanisms: Silent mode, warning mode and exception mode (http://www.php.net/manual/en/pdo.error-handling.php).
The problem is that each mode requires a different type of error handling code. Accepting that I can't force the user to use my preferred mode, i think that my options are:
Setting my preferred mode on the inputted PDO object, and worrying about nothing
Cloning the inputted PDO object and then setting my preferred mode
Writing error handling code for all 3 modes and then detecting and employing the appropriate one with the help of PDO::getAttribute() method
Setting my preferred mode before each method call and then revoking it after each one
So 1 can break user's code, 2 looks like unnecessary duplication, 3 is terribly awkward, and 4 is not-so-terribly-awkward-but-still-awkward and still susceptible to breaking user's code.
So i'm asking to library writers out there, how do you handle this?

Answer 1

Ok, not sure if this is the right site for this sort of question, but first, let me give you the short run-down of your options, and tell you what IMO is the better option. Then I'll explain all of it in future edits.
That's not the way forward. The user is passing an instance, which you then change, behind the users' back. Don't change what isn't yours
Don't clone a DB connection. Just don't
A library shouldn't deal with errors that are the result of the user's code. That's the user's problem/fault, they should then also deal with it. No way a lib can anticipate on every possible abuse
No, really... This is just a silent way of doing what you're doing in point 1: changing an object you never really owned.
What, then, would I do? Simple: Provide an API for DB connections that could, in its heart have a PDO instance, but then at least the user has a clear API, and knows what the result of possible errors are (for example PDO + setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION) => your API will always throw exceptions
Now, why is your first option not a viable approach? (again: this is all my opinion)
Suppose I were to use your code, and have something like this:
//code
$this->db = new PDO($dsn, $usr, $pass, array(PDO::ATTR_ERRMODE => PDO::ERRMODE_SILENT));
$this->dependency = new Your\Lib\Stuff($this->db);
//code
$this->db->query('bad query');
Now if you set PDO to throw exceptions, I'm not catching any. My code wasn't writtin in a way to deal with PDOException instances, so it'll cause the entire app to grind to a halt. What's more, who's to say that I'm not going to add this line, while debugging, when that happens:
$this->dependency = new Your\Lib\Stuff($this->db);
$this->db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT);//override your setting
This isn't a safe path to go down, so don't.
Next: cloning PDO just won't work. If you have a silly person who wrote his own class to extend from PDO, this is possible:
class BadIdea extends PDO
{
public function __clone()
{//disable clone
return false;
}
}
In this case $db = new BadIdea() will still pass as an instance of PDO (test function foo(PDO $arg){echo 'argument is instance of PDO';} and then call foo(new BadIdea), it will work). Now you can't clone, and your lib fails.
A lib or framework should be written generically enough so you can reuse it. If you're writing the code, while thinking of a particular use-case in mind, you're probably going find yourself editing the code every time you wish to use it again.
Unless you're going to be creating your own lib (in which case the user wouldn't have to pass a self-made DB connection anyway), error handling shouldn't be the task of your lib.
Your code should just throw exceptions when something happens that is unexpected. You can't be expected to write code that deals with all of these situations:
$yourInstance->pass('Invalid query');
$yourInstance->select('INSERT ...');//valid query, wrong method
$your instance->query(array('invalid', 'argument'));
Or worse:
try
{
$yourInstance->beginTransaction();
$yourInstance->query($q1);
$q2 = $anotherObj->composeComplexQuery();//might be the cause of Exceptions, too
$yourInstance->query($q2);
$yourInstance->commit();
} catch(){}
When you deal with errors inside of your lib, then how will your user be able to deal with situations like these? a transaction is a concious decision made by the user, any exception that might occur during a transaction, be it an error in the queries or an exception thrown by third-party methods can result in the transaction having to be rolled back.
Your lib's scope isn't wide enough to pick up on the exceptions that are thrown in the user's code.