On 25.10.2022 at 14:10, BohwaZ wrote: >> As others have said, the correct, responsible way to do this would be >> to make it gradual and keep warnings working until 9.0. I would >> recommend: >> >> 1. 8.3, enableExceptions(false) raises E_DEPRECATED. >> 2. 9.0 enableExceptions() defaults to true, and calling it with false >> is an Error. (Calling it with true still works, but is a no-op.) 3. >> 10.0 Remove enableExceptions() entirely. >> >> The behavior then only changes on major versions. > > Thank you, I updated the RFC in that direction. The sad part is that it > will take a very long time before PHP 10.0 is released :(
Cf. <https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003>, where we changed the behavior in a minor release. Not quite the same as in this case, but might still be a precendence. >> I think we already did this for PDO, didn't we? It makes sense to do >> it for SQLite, too. > > Slightly different: > https://wiki.php.net/rfc/pdo_default_errmode > > PDO made the change to throwing exceptions without going through a > deprecation. > > Maybe what I would prefer for SQLite3 is a middle-ground: > * we keep ''enableExceptions(false)'' with no plan to remove it -> > thinking about it, it doesn't really matter if you prefer warnings, > and it would be easy to keep it that way No, please get rid of the choice for users whether there is an exception or a warning. As it is now, it is *very* hard to document the behavior; what to put in the errors/exceptions section, for instance. Several other extensions have the same issue, and we should try to fade that out. > * but we make SQLite3 throw exceptions by default directly in PHP 8.3, > like it was done with PDO 2 years ago. > > That way you can keep the same behaviour as before just by adding > enableExceptions(false) to your code, and it will not break. > > That seems like a better compromise no? -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
