Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104536 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 32109 invoked from network); 1 Mar 2019 15:15:26 -0000 Received: from unknown (HELO mail.gna.ch) (62.12.172.119) by pb1.pair.com with SMTP; 1 Mar 2019 15:15:26 -0000 Received: from [10.0.1.55] (77-56-180-37.dclient.hispeed.ch [77.56.180.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 77D0D20FE7; Fri, 1 Mar 2019 13:02:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) In-Reply-To: Date: Fri, 1 Mar 2019 13:02:29 +0100 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <226B512C-02A7-4555-9288-D7A2DA89F068@benramsey.com> To: Nikita Popov X-Mailer: Apple Mail (2.3445.102.3) Subject: Re: [PHP-DEV] [RFC] Consistent type errors for internal functions From: cschneid@cschneid.com (Christian Schneider) Am 17.02.2019 um 17:24 schrieb Nikita Popov : > 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:=20 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