On Tue, Jan 26, 2021 at 8:42 AM Christian Schneider <cschn...@cschneid.com> wrote:
> Am 26.01.2021 um 07:57 schrieb Alexandru Pătrănescu <dreal...@gmail.com>: > > There will be other parts that will require testing, whatever you do. > Trying to optimize this to reduce the 1 line quick fix that could be easily > read in the documentation at https://www.php.net/manual/en/migration81.php > <https://www.php.net/manual/en/migration81.php> sounds to me like we're > trying too hard to reduce this cost, ignoring others. > > The migration guides are already getting quite long, just have a look at > https://www.php.net/manual/de/migration80.incompatible.php < > https://www.php.net/manual/de/migration80.incompatible.php> > "Just one more line" can add up and that's why I want to be able to > proactively fix my code, not fixing it at the time of migration. > > If the error mode would be changed to warnings instead of exceptions first > then every developer interested in best practices could and would already > adapt their code. But they could do it gradually without the disruption of > hard fails looming over them. > > I just think giving developers a warning period (per default, not opt-in) > is the right thing to do for BC breaks. [ Did I mention round()? ;-) ] > > I start to sound like a broken record, I'll leave it at that, > - Chris > I think if you wanted to introduce an additional diagnostic step, the way to go about it would be to issue a deprecation warning when creating a connection without mysqli_report() having been explicitly called beforehand. As others have said, the warning mode is pretty much entirely useless, and what you really want (presumably) is to know about the places where you need to explicitly call mysqli_report() to preserve the old behavior (or explicitly switch to the new one). Regards, Nikita
