Hello,
It is now possible to vote on the RFC "Throw exception for invalid characters in number base functions".
RFC: https://wiki.php.net/rfc/throw_error_for_invalid_characters_for_number_base
Latest discussion: https://news-web.php.net/php.internals/132379
PR: https://github.com/php/php-src/pull/22365
There is one item to vote on: Throw a Exception for invalid characters in number base conversion functions?
Regards,
Sjoerd Langkemper
Hi,
I've voted against on this RFC, and the only reason is the choice of a
generic \Exception.
The original Base Convert Improvements RFC (
https://wiki.php.net/rfc/base_convert_improvements
https://wiki.php.net/rfc/base_convert_improvements) already set out the
intended path:
This vote will be to raise a
E_DEPRECATEDwarning for PHP 7.4. Raising to
be anInvalidArgumentExceptionin PHP 8
I agree with moving away from ValueError for the reasons given in the RFC.
However, InvalidArgumentException, which was the exception originally
agreed upon, wasn't brought up.
The Rejected Features section notes that SPL exceptions shouldn't be thrown
from ext/standard. If that's the blocker, I'd rather see it resolved (or a
dedicated exception class introduced) than have a core function throw a bare
\Exception, which users can only catch together with every other exception.
Regards,
CHU Zhaowei
Hi CHU Zhaowei,
Thank you for your explanation.
I’ve voted against on this RFC, and the only reason is the choice of a generic \Exception.
Yes, this is fair. A more specific exception is desirable, but currently not easy to get right. Throwing a generic Exception now makes it possible to change this later to something more specific.
InvalidArgumentException, which was the exception originally agreed upon, wasn’t brought up.
I would have preferred it if you brought this up during the discussion phase.
InvalidArgumentException is definitely the incorrect exception to use. First, because it is documented as indicating that the argument is not of the expected type. Second, because it extends from LogicException, which indicates a programming error. Having these function fail is not necessarily programming error, it could be unexpected user input. This was also the argument Tim made against ValueError.
During the discussion phase, Lazare suggested UnexpectedValueException, which is also an SPL exception and also not semantically correct. So while InvalidArgumentException specifically was not discussed, there was some talk about more specific exceptions.
SPL exceptions shouldn’t be thrown from ext/standard. If that’s the blocker, I’d rather see it resolved
Yes, the SPL exceptions are now of limited use and partially overlap with other things such as ValueError. I would think there would already be an exception I could reuse for the simple case where an argument cannot be processed, but apparently not. The transitions to namespaces and exceptions just has not progressed that far. If you have any suggestion to improve the situation, please let us know.
Regards,
Sjoerd