Hi Sherif,
2013/6/29 Sherif Ramadan <theanomaly...@gmail.com>
>
> If we tried to fix all of PHP's functions to either return false always or
> return false and raise errors always we'd have to fix every single PHP
> function there is since there's absolutely no consistency there as it is.
>
>
We don't have to change them all. Whether function should raise error or
just return false determined by use case. For instance, raising error in
base64_decode() would be annoying.
> Different functions handle failure differently, and not all functions
> report every possible error they may encounter. Take functions like
> file_get_contents, for example, where it wraps other API functions that
> could RETURN_FAILURE and/or trigger the error handler, and
> file_get_contents isn't even documented to raise those errors in some cases.
>
> I see these as two separate problems. The first problem is clearly a
> design problem (but we can't really do much about that in the short term).
> The second is a documentation problem. Beyond that there are users that
> don't clearly understand the behavior of some functions due to the previous
> two reasons.
>
Third problem. There should be error/exception handling guideline for
developers.
>
>
>> Considering the use case of hex2bin(), it will not handle external inputs
>> in most cases. Therefore, it's better to raise errors invalid inputs. Do
>> you prefer not to raise errors?
>>
>
> Considering the fact that we have a discussion in the bug report mentioned
> earlier (and it was an extensive discussion because not only were our users
> confused but even our core developers were confused if you read the
> responses in that bug report), I would prefer that we leave the function
> the way it is.
>
> The error was added for a very specific reason. People thought it was
> doing what pack('h*', $hex) does, and clearly it wasn't. So the
> documentation was also updated to make note of this and explain it to the
> user, along with the helpful error message to indicate that hex2bin('f')
> would not work.
>
I respect the discussion. However, it does not matter to new comers.
Raising E_WARING for bad length while simply return false for bad hex does
not make sense.
> I don't think there was ever any expectation for the user to do something
> like hex2bin('Hello World') and expect any kind of sensible result. The
> error really does not inform them of anything useful.
>
There is different view for this. Supplying invalid string to hex2bin() is
obvious bug or attack. It would worth to notify users there is obvious
problem.
I didn't want to take vote for such small change. I hope you've convinced.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
