Hi Chris,
Apologies but I assumed your lack of further response or comment meant
that my response had cleared up the issues you had with the suggested
change.
I particularly expected a response in this case since I had questions
about (my understanding of) your response - specifically where you
talked about "deprecation", which to me, in the context of changes to
PHP, means emitting a deprecation notice in some way, and how you saw
that would be implemented in the context of this change.
The issue was further not raised when I presented the RFC with no open
issues or discussion of warnings or deprecation, which I further took to
mean that you no longer had any issue.
While I get that this can be a busy list and there are occasions where
you want to withdraw from further discussion to prevent things going
around in circles or getting too astray of the point at hand, as a first
time RFC submitter what am I supposed to do when there's no response to
my request for clarification?
With regards to changing the PDO error mode to warnings first, I would
make the following points:
PHP has been in the process of upgrading many notices and warnings to
thrown errors and introducing new ones throughout the PHP 7 era and
going forward into PHP 8, and thrown exceptions or errors is the way I
think (particularly newer) users of PHP (will) expect things to happen now.
If the default were switched to warnings first, particularly if there's
no obvious sign to expect it to change again in the future, new users
would learn how to handle PDO errors as warnings (while the rest of PHP
primarily uses thrown errors / exceptions), then have to update their
code again when it switches to exceptions (this may also apply to the
tutorials and guides they follow). (Existing users are much more likely
to go about explicitly setting the error mode, or at least knowing how
to, but new users are, in my opinion, much more likely to stick and
learn with the defaults)
An error from the database server is an error, not a warning (MySQL at
least has its own concept of warnings, which, from what I've read, the
client gets a count of with the initial resultset response but PDO
provides no access to) and usually means that the code cannot sensibly
continue (this is somewhat mitigated by the fact that you'll usually get
subsequent errors attempting to process the resultset - but may not
always be the case). Throwing an exception is the safest way to help
ensure data integrity, in my opinion. (There will be some cases where
people are expecting something may fail and want to ignore that failure
- PHP's test suite currently does this when deleting test tables in its
PDO factory/constructor - but I would argue that the code should show
this expectation)
This change is already being made in a major version. It's the sort of
change I'd fully expect from a major version. While I understand the
desire to reduce the magnitude of breaking changes, I would also argue
that keeping their frequency low is just as important (particularly
if/when there is no warning that there will be a further change).
An alternative would be to force the developer to explictily set the
error mode, but I don't see why that should be the case when anything
but silent is a good default (with exceptions just being a better
default for modern PHP in my opinion).
Regards,
AllenJB
On 14/04/2020 07:52, Christian Schneider wrote:
