Re: [RFC] Consistent type errors for internal functions

Am 17.02.2019 um 17:24 schrieb Nikita Popov <nikita.ppv@gmail.com>: > 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. I have an example where this might be harder than necessary: I'm importing data from an external source. Now in the real-world the import data files can once in a blue moon contain bogus data, e.g. there could be an array instead of a string in one single entry and I'm doing a strlen() on it. Previously this triggered a Warning but the import job completed for all the other entries while still informing me that something was amiss. The new way leaves me with three options: 1) My import jobs stops at the single broken entry 2) I can add type-checks for every single field 3) I can start wrapping code with try/catch Neither of the three options are very appealing to me. Option 1) might be appropriate when you are importing data which life and death depends on but for lots of stuff you're more interested in having the other 99% of your data updated instead of failing completely. Option 2) sounds like the most defensive way of programming but it adds lots of boiler-plate code and doesn't feel phpish to me. Option 3) is Java's RuntimeExceptions madness all over again which is surprisingly had to get right (where to catch what). I'm a bit surprised the PHP community had such a change of mind concerning Exception in the core and BC breaks over the last years but as the vote seems very much to be in favour of this change I guess I'll have to bite the bullet once PHP 8 arrives. Regards, - Chris