Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113008
To: Kamil Tekiela <tekiela246@gmail.com>,
 Christian Schneider <cschneid@cschneid.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAGBsUrddzJQu3JtqCdLjyHOBf71gj5LpNKuV=OmYGm0Vd3n9Yw@mail.gmail.com>
 <0edafce4-c9a5-c483-65f1-72e49614135a@telia.com>
 <CAGBsUreBNSkv7KY6FRw-c0SfWDMs9H+aTFG_e89wUSmf53DWkQ@mail.gmail.com>
 <AAA0C162-26F9-4F06-8509-F3C96C0DAEA3@cschneid.com>
 <CAFPFaMJE-YzYv1nW9t8974CmigrmBtQTQR67BaQ7zbM0B1U4+g@mail.gmail.com>
 <EFFA9BF8-1C86-42E4-9A13-8203B920C81A@cschneid.com>
 <CAFPFaMKH2rT=9E5ka5YP7DYjZ243QVj-Oj3Bm9kAoA=WBPH2bw@mail.gmail.com>
 <4D7D042F-39A5-4BEF-93B6-542FD53928A1@cschneid.com>
 <CAAwdEzD84xDnUsOLBTP_BfrT8s97GkOM-aQ7rk7R6x5OFcmVZw@mail.gmail.com>
 <73C12DD2-D99E-44BA-B557-6043F3DDD4C7@cschneid.com>
 <CAF+90c_QC6wbzQLop3Xyp1RUEeBVSttz6T9KgV4DBJmEL9hmpA@mail.gmail.com>
 <30C0E1A8-6269-4221-AF21-3FA738D5910C@cschneid.com>
 <CAGBsUrfePS2Gnh4xQMQFEnUVXGTdgMhaPP5reLLcKR+nEp59Yw@mail.gmail.com>
 <0eb16a55-92d0-7118-57fe-0f3f7d2bc351@telia.com>
Message-ID: <95c3196d-106b-8964-ddd5-9069eb333a61@telia.com>
Date: Wed, 27 Jan 2021 17:39:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <0eb16a55-92d0-7118-57fe-0f3f7d2bc351@telia.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

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.