Re: [RFC] Consistent type errors for internal functions

On Sat, Feb 16, 2019 at 6:34 PM Ben Ramsey <ben@benramsey.com> wrote: > > On Feb 5, 2019, at 05:22, Nikita Popov <nikita.ppv@gmail.com> wrote: > > > > Hi internals, > > > > I'd like to bring forward the following proposal for PHP 8, which will > make > > (zpp) parameter parsing failures always result in a TypeError (rather > than > > generating a warning+null, depending on circumstances): > > > > https://wiki.php.net/rfc/consistent_type_errors > > > > The goal here is to remove one of the inconsistencies between > user-defined > > and internal functions, and to put us in a position where we can actually > > start specifying type information in arginfo without fear of breaking > > things. > > > I like this RFC, and from a user perspective, this consistency is > much-needed. > > While warnings don’t affect continued processing, uncaught TypeErrors do. > What is the recommended upgrade path for users? How will this affect the > silence @-operator, since I’m sure many users use that to squelch these > warnings, and they accept the null or false return value as acceptable for > processing the rest of the script. > > Cheers, > Ben > The recommended upgrade path here is basically "deal with it". If a codebase does this (intentionally calling functions with invalid params and suppressing errors) a lot, then it might make sense to register an error handler that collects all "expected parameter" style errors in a production environment, to easily identify all code that needs to be fixed. The error messages have a consistent format, so it should be simple to identify and eliminate all warnings of this type. Nikita