Am 17.02.2019 um 17:24 schrieb Nikita Popov <nikita....@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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to