Den 2021-01-27 kl. 17:13, skrev Björn Larsson:
Den 2021-01-27 kl. 16:07, skrev Kamil Tekiela:
Wouldn't this mean everybody would add mysqli_report() to their code?
That is the idea. That is what everyone should already have in their
codebase.
And wouldn't this render the default of mysqli_report() entirely
useless?
I'm sorry, but I don't follow the train of thought? Why would it make
that
useless? You must set the correct error reporting mode anyway and that
function helps in doing so.
Or is your idea that at a later stage you then want to create a
warning
for manual mysqli_report() calls?
What are manual mysqli_report() calls? You either have that line in your
code or you don't. The idea that Nikita suggested is to meet your
concerns.
The only way to figure out if your code needs an adjustment is to have a
warning emitted from any mysqli connect methods if you have not called
mysqli_report before. It would inform users that they are missing the
setting.
No, I want to know if I have any code which needs fixing so I can
see how
I want to change those places e.g. a duplicate key from INSERT to
REPLACE
or whatever the correct fix is. Without the code aborting.
You can do that right now. This proposal will not make it easier or more
difficult for you to do that. Just paste
mysqli_report(MYSQLI_REPORT_ERROR)
before mysqli_connect() and PHP will generate a warning whenever your
SQL
throws an error.
Otherwise the temptation is big to just add a global
mysqli_report(MYSQLI_REPORT_OFF) everywhere just in case.
I don't get what's wrong with that. This is literally what I said in the
RFC you can do if you don't want mysqli to report any errors. Whoever
doesn't want to see errors can use this line to silence them.
I would even make a counterpoint. If we set MYSQLI_REPORT_ERROR as the
default then users will definitely silence errors and forget. The
warning
mode is so useless and annoying that people will prefer to silence it
seeing no benefit to it. If we want this change to be useful then we
should
make SQL errors report as exceptions by default.
Regarding Nikita's proposal: The compromise is reasonable, but this will
not be well-received by the community. Additional warnings will only
make
things more confusing without providing outstanding benefits. If we
want to
force people to set the error reporting mode that they want, then it
would
be better to set a sensible default value and give a clear
explanation in
the migration guide how to set it back to the previous value. Of
course, I
don't hate Nikita's proposal and I might say I even like it a little
bit,
but only in connection with exception mode as the default value. This
way
users will not be surprised by an exception if it happens that they
forget
to silence. But I would prefer that everyone embraced exceptions.
I'm missing a thing here when we talk about "your code". I mean on our
site
we have third party libraries. They can typically have a release
schedule on
a couple of releases each year. So all code is not up to us to change.
So how
does this proposal adress that scenario when it's not up to us to do the
necessary changes? Is it e.g. a blocker to upgrade to PHP 8.1 with
exceptions vs warnings until the library is updated?
As a side note I'm at the moment migrating our test site to PHP 8 and
the two most prominent hickups are located in a third party library:
"Undefined array key" and "Attempt to read property "value" on null"
which are warnings. Not sure how it would have been with these as
exceptions, e.g. would the test site stop running and thereby stop
testing of other parts.
And as I have said earlier, I do like exceptions! It's the migration
aspect I'm wondering about...
r//Björn L
PS And sorry for the lousy formatting in earlier response.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
