On 03/12/2018 09:43 AM, Sara Golemon wrote:
On Mon, Mar 12, 2018 at 11:32 AM, Christoph M. Becker <cmbecke...@gmx.de> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
