Re: Re: [RFC] Base Conversion Clowniness

On 03/12/2018 09:43 AM, Sara Golemon wrote:

On Mon, Mar 12, 2018 at 11:32 AM, Christoph M. Becker <cmbecker69@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.