Bug #64705 errorInfo property of PDOException is null when PDO::__construct() fails

[kalaspuffar]

Changes:

• Extended zend_throw_exception_ex and created a pdo_throw_exception_ex that will populate the errorInfo property of the PDOException class.
• Added testcase for Bug #64705 errorInfo property of PDOException is null when PDO::__construct() fails.
• Changed all drivers so they use pdo_throw_exception_ex instead of zend_throw_exception_ex.

Tested with:

• DSN sqlite - sqlite memory database
• DSN mysql - mysql database locally
• DSN pgsql - postgresql database locally
• DSN odbc - db2 database locally
• DSN firebird - firebird database locally
• DSN oci - oracle database locally
• DSN dblib - mssql database Amazon EC2

[kalaspuffar]

After reading the comments closely on the comments on the document page I suggest we make a document change to be more explicit and change what code is.

An exception has a code int that is populated from the internal error code from the different PDO drivers. But the SQLState (5 char) should not override this in the PDOException implementation. This makes the class hard to use and does not work with already written tests.

So my suggestion is that we keep the code int and return the errorInfo structure as normal with the SQLState included.

Exception::errorInfo = array(3) {
[0]=>
string(5) "%s"
[1]=>
int(%d)
[2]=>
string(%d) "SQLSTATE[%s]%A"
}

So index 0 is the state, index 1 is the driver code and lastly index 2 is the message.
Same driver code is the exception code. And the message is also the same for the Exception.

Have a value being both a String and Int at the same time will confuse unnecessarily.

[smalyshev]

Every time pdo_throw_exception_ex is ever called exception_ce parameter is always php_pdo_get_exception(). Since this is clearly a PDO-specific function, maybe this parameter should be eliminated and this function should call php_pdo_get_exception() instead?

[kalaspuffar]

Well, zend_throw_exception_ex was extendable so I wanted to keep that option, but your right this is possibly not required or wanted in a library where the purpose is to unify driver interaction.

[krakjoe]

Since this targets a security fix only branch, and since a patch against a supported branch would have to be different, I'm closing this PR.

Please take this action as encouragement to open a clean PR against a supported branch, in addition please leave whitespace changes out of any subsequent PR, and make those as separate PR's.

[kalaspuffar]

@krakjoe Thank you for the feedback.