Bug #79769 [Nab]: PDO throws non-PDO exeptions

Edit report at https://bugs.php.net/bug.php?id=79769&edit=1 ID: 79769 User updated by: morozov at tut dot by Reported by: morozov at tut dot by Summary: PDO throws non-PDO exeptions Status: Not a bug Type: Bug Package: PDO Core Operating System: Linux PHP Version: 7.4.7 Block user comment: N Private report: N New Comment: > The user shouldn't be catching the exception, they should be fixing the code that resulted > in the exception being thrown. This is the case for all exceptions that subclass Error. This explains everything. Thank you. I agree with the “not a bug” resolution. Previous Comments: ------------------------------------------------------------------------ [2020-07-02 07:21:14] nikic@php.net The user shouldn't be catching the exception, they should be fixing the code that resulted in the exception being thrown. This is the case for all exceptions that subclass Error. ------------------------------------------------------------------------ [2020-07-02 06:55:14] requinix@php.net It isn't an "implementation detail" when the documentation for bindValue says that the values given to it will be treated as strings by default. ------------------------------------------------------------------------ [2020-07-02 06:41:45] morozov at tut dot by The fact that the library converts something to a string internally is an implementation detail and shouldn't be leaked outside. Otherwise, what type of exceptions should the consumer be catching when using the library? ------------------------------------------------------------------------ [2020-07-02 06:00:10] requinix@php.net The exception is not coming from PDO. It's coming from PHP. It happened when PDO tried to convert the value to a string, and if your own library tried to do the same thing then PHP would react the same way. ------------------------------------------------------------------------ [2020-07-02 04:39:57] morozov at tut dot by Description: ------------ When interacting with a PDOStatement object, the consumer should be able to expect all exceptions to be reported as PDOException. However, in certain cases, the extension leaks its internal implementation details and throws an Error. Test script: --------------- <?php $conn = new PDO('sqlite:memory:'); $stmt = $conn->prepare('SELECT ?'); $stmt->bindValue(1, new DateTime()); try { $stmt->bindValue(1, new DateTime()); } catch (Throwable $e) { echo get_class($e), ': ', $e->getMessage(), PHP_EOL; } try { $stmt->execute([new DateTime()]); } catch (Throwable $e) { echo get_class($e), ': ', $e->getMessage(), PHP_EOL; } // the above seems to be implemented just by casting the value to a string since it behaves exactly as the following: try { (string) (new DateTime()); } catch (Throwable $e) { echo get_class($e), ': ', $e->getMessage(), PHP_EOL; } Expected result: ---------------- A PDOException is thrown instead of an Error PDOException: Some message that says that this type cannot be bound to the statement Actual result: -------------- Error: Object of class DateTime could not be converted to string ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=79769&edit=1