Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101971 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70788 invoked from network); 12 Mar 2018 17:06:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Mar 2018 17:06:01 -0000 Authentication-Results: pb1.pair.com header.from=alice@librelamp.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=alice@librelamp.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain librelamp.com designates 45.79.96.192 as permitted sender) X-PHP-List-Original-Sender: alice@librelamp.com X-Host-Fingerprint: 45.79.96.192 librelamp.com Received: from [45.79.96.192] ([45.79.96.192:34552] helo=librelamp.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 29/2F-24487-873B6AA5 for ; Mon, 12 Mar 2018 12:06:00 -0500 Received: from localhost.localdomain (230.sub-174-215-9.myvzw.com [174.215.9.230]) by librelamp.com (Postfix) with ESMTPSA id 5E23D1237 for ; Mon, 12 Mar 2018 17:05:57 +0000 (UTC) To: internals@lists.php.net References: <1e29d1b7-dbf4-35d5-61cc-8348c195984a@gmx.de> Message-ID: Date: Mon, 12 Mar 2018 10:05:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC] Base Conversion Clowniness From: alice@librelamp.com (Alice Wonder) On 03/12/2018 09:43 AM, Sara Golemon wrote: > On Mon, Mar 12, 2018 at 11:32 AM, Christoph M. Becker wrote: >> I tend to prefer option C (throw a Warning, stop processing, and return >> the value up to that point). Option B (throw a Warning and return FALSE >> on unexpected characters) might be cleaner, but we're not that picky >> elsewhere, and the return value might not even be checked, and thus >> easily misinterpreted as zero. >> > I've also added option D: Throw an exception. I'm not a computer science guru but that is what I was thinking should happen. The only way bad arguments should get to that point where this issue occurs is if the programmer did not properly validate the data. I don't like that PHP is often very forgiving and recasts types (I guess what they call loose type), I personally think if it is appropriate to recast the programmer should identify the that it is a safe scenario to recast and recast intentionally. I'm a huge fan of throwing \TypeError from within my own classes when a parameter is incorrect and \InvalidArgumentException when the type is correct but the argument is absurd. If it would break code, keep the existing behavior during the next release but log a warning - just like is done with deprecation, but the release after, I agree throw an exception. An exception is better than GIGO - an exception lets the coder know they have a mistake.