Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104544
Date: Sat, 02 Mar 2019 09:45:22 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <C8E2ED8A-D5CA-4BED-8E22-674B074ECF27@cschneid.com>
References: <CAF+90c9E6O-12fKKY_kb5b_LvXgODbPpC73TNro+XpMewndT2Q@mail.gmail.com> <226B512C-02A7-4555-9288-D7A2DA89F068@benramsey.com> <CAF+90c9uVdc7s9Q2bJtkhGWGkk3J5u9+qenEtNvGhFDL+cg-WQ@mail.gmail.com> <C8E2ED8A-D5CA-4BED-8E22-674B074ECF27@cschneid.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net,Christian Schneider <cschneid@cschneid.com>,Nikita Popov <nikita.ppv@gmail.com>
CC: PHP internals <internals@lists.php.net>
Message-ID: <49A08E7C-22CA-4165-AF33-61E19D4E360D@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Consistent type errors for internal functions
From: rowan.collins@gmail.com (Rowan Collins)

On 1 March 2019 12:02:29 GMT+00:00, Christian Schneider <cschneid@cschneid=
=2Ecom> wrote:
>I have an example where this might be harder than necessary:
>I'm importing data from an external source=2E Now in the real-world the
>import data files can once in a blue moon contain bogus data, e=2Eg=2E
>there could be an array instead of a string in one single entry and I'm
>doing a strlen() on it=2E
>
>Previously this triggered a Warning but the import job completed for
>all the other entries while still informing me that something was
>amiss=2E

The problem with Warnings is that processing doesn't just continue for all=
 the *other* entries, it continues with *this entry that turned out to be b=
ogus*=2E So now rather than a missing record, you have a record containing =
a 0, or the word "array", etc; and the Warning probably won't tell you whic=
h record it was that failed=2E


>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

Option 2 can be stated differently as "add validation for each input recor=
d": this isn't the same kind of type check as a library function picking up=
 coding mistakes, it's handling of untrusted input=2E

Option 3 can be thought of as the transactional approach: if an error happ=
ens within a logical record, you can log that record to a reject file and c=
ontinue with the next record=2E

There is definitely more effort to doing one of these compared to not doin=
g it, but both seem preferable to letting bad data through, whether the lan=
guage forces you to do something or not=2E

Regards,

--=20
Rowan Collins
[IMSoP]