Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112961 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 33787 invoked from network); 21 Jan 2021 23:06:15 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Jan 2021 23:06:15 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 947FB1804D3 for ; Thu, 21 Jan 2021 14:46:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 21 Jan 2021 14:46:34 -0800 (PST) Received: by mail-ed1-f42.google.com with SMTP id c2so4170642edr.11 for ; Thu, 21 Jan 2021 14:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OFDSDEP88dhhON7nDw6MRf8DMr+Tz3FSyaB0FVPfcOs=; b=dF/LDg/fzyg8jAq1ycwPAJn9YfiUaDcPq+Mn01TvJ8zbEchb+o0musxzM1oLqD4Y75 IxrQJpg9nNPwtORApinytSLwhuqpa/oBEE8aRgYpCvIdrvqE93VwUHPxTYGKx6dJJx5U DnZIdaUpfDyQrmZ/HtBGl/zyc9abnCvv0pO/eDNp2hXYmPPoVOq+nwEYXrGCvSX+XUF5 kSavZXh8g/ZP7K9xgybeRwlLNQjFeFgUoMhTF9FIf32tRY0Ip8/BujI1TRW8auwX0wtf hcgvUbADN3j9Ln4IpVJKDqgdOm+oMQpULHgfdCJR4fg7FJRhBbg0iiIgJjdEdbOHv/SP PrNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OFDSDEP88dhhON7nDw6MRf8DMr+Tz3FSyaB0FVPfcOs=; b=D9XImZLCjGNT2iQAerYhYpBt0TqIW70OdbryUhxM3i/EJwqClEpDLLrYpAZFdapcoA LXiMEhWrARrhz4ckiQOCZm9WUANwbPg3W5l2Z7GeAXUEEC/XR+ysZ2oX/yD54TzcL7tW oWG7sSN/Q7vUhyToNDNA7zvweAWv6HnqpkB5vfbPPfPpnYtMxzaEfmmtJu3V/m/SsYkj OeD7M5x8PDQ+m64sTNw124V2gaNLgFgkCq/WczcgK7cepSqEn3HPAfrrOuHHE1Y4ZBFq 3qiaDkIxSWX4Bv6ylz1VfJSTATMlnm9etpV6vmg3VcUYefF4JBmmIHK6mxw/U0u9Xm9j 6fmw== X-Gm-Message-State: AOAM532xm7kflGiPTVdMZ0pxnOt1Zv1Aj7Od9N6wEkGpXQIi1gXcFw2/ jbVlbsvxk/pOfByDePoCNIvIiC91FgjggyV9XpM= X-Google-Smtp-Source: ABdhPJytfFkNxU6ltKtVkB9Wiqw1X265DSJhk2A6UCfnzqr4mp2IrgvG+ixLkoLK/C7Sdl/5aa6CRKDKKVfBysO/Uuw= X-Received: by 2002:a50:b246:: with SMTP id o64mr1019414edd.132.1611269191274; Thu, 21 Jan 2021 14:46:31 -0800 (PST) MIME-Version: 1.0 References: <0edafce4-c9a5-c483-65f1-72e49614135a@telia.com> In-Reply-To: <0edafce4-c9a5-c483-65f1-72e49614135a@telia.com> Date: Thu, 21 Jan 2021 22:46:20 +0000 Message-ID: To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000c8945405b970d7f6" Subject: Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode From: tekiela246@gmail.com (Kamil Tekiela) --000000000000c8945405b970d7f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 21 Jan 2021 at 21:51, Bj=C3=B6rn Larsson wrote: > If I understand this correctly, does it imply that a lot of > legacy code that works today, will not work any longer and > needs to change? Like: > if ("mysqlierror") { > "error handling" > } > > If so I think that like in other RFC's an investigation should > be done on how much code that is affected to assess BC impact. > The code will still work as it did before, but if there is an error then an exception will be thrown. This means that by default the custom error handlers will become redundant. Generally, this should not be a problem, but I can imagine that some projects heavily rely upon the manual error checking. Among the popular PHP projects that I know of, only CodeIgniter and WordPress still use mysqli. CI does offer PDO as an option but due to legacy reasons, many people still chose mysqli. However, they already use the exception mode. https://github.com/codeigniter4/CodeIgniter4/blob/d5673f4376dc981196607bc15= 9368bee9990033c/system/Database/MySQLi/Connection.php#L94 WordPress ... the black sheep of PHP ... uses mysqli with a fallback to mysql_* API. They use manual error handling, which would be replaced by normal exceptions unless they silence it. They should modernize their codebase at some point as they can't cling on to the past forever. For the moment if they want to continue using manual error checking then they need to explicitly disable mysqli errors without relying on the default setting. That is only 1 additional line of code. This would be the same as what I have done in PHP internal test cases. I don't see any problems there. In fact, I don't really see this as a major breaking change. If any project really needs the mysqli errors silenced then they can just set the error mode back to OFF. The change is aimed at new users, not existing projects. Silenced error reporting was a source of confusion for plenty of beginners who were unaware of the setting. Kind Regards, Kamil Tekiela --000000000000c8945405b970d7f6--