Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118876
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Mon, 24 Oct 2022 10:42:44 +0200
References: <20221024045645.00bfc0d2@platypus>
To: PHP Internals <internals@lists.php.net>
In-Reply-To: <20221024045645.00bfc0d2@platypus>
Message-ID: <870F98D7-A5D2-48EB-B992-5B4EDDD1B1DA@cschneid.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to
 exceptions
From: cschneid@cschneid.com (Christian Schneider)

Am 24.10.2022 um 04:56 schrieb BohwaZ <php@bohwaz.net>:
> I am proposing that the SQLite3 extension stops using warnings for
> errors and instead throws exceptions by default:
>=20
> https://wiki.php.net/rfc/sqlite3_exceptions
>=20
> Whether we just deprecate warnings first and default to exceptions, =
and
> then remove warnings altogether in a later version, or just disable
> warnings directly, is probably the important part of the RFC.
>=20
> My personal point of view is that modern code probably already have
> enabled exceptions in the class, or is transforming warnings into
> exceptions using an error handler.
>=20
> If not, it's relatively easy to set a exception handler to dismiss the
> new exceptions if you don't want to see them.
>=20
> So going throught depreciation might not be necessary, but it's open
> for discussion.

To no surprise for anyone reading this list I'm going to strongly =
advocate for going through a deprecation phase to ease migration of =
code.
As often the code changes needed might not be big but you still have to =
a) notice all the necessary changes (the SQLite exceptions might just be =
one of many changes in the new PHP version) and b) adapting the code =
should be decoupled from the PHP upgrade. Both of these goals are IMHO =
well handled by a deprecation phase.

Regards,
- Chris