Repository navigation
ValueError: NumberFormatter::format(): Argument #3 must be a NumberFormatter::TYPE_* constant #9421
Description
Description
from the php manual
public NumberFormatter::format(int|float $num, int $type = NumberFormatter::TYPE_DEFAULT): string|false
not quite sure about this mystical argument # 3.
$Fmt = new NumberFormatter('en_US', NumberFormatter::CURRENCY);
var_dump($Fmt->format(1234.45, NumberFormatter::TYPE_CURRENCY));Resulted in this output:
Output for 8.0.1 - 8.0.22, 8.1.0 - 8.1.9
Fatal error: Uncaught ValueError: NumberFormatter::format(): Argument #3 must be a NumberFormatter::TYPE_* constant in /in/mc4XU:4
Stack trace:
#0 /in/mc4XU(4): NumberFormatter->format(1234.45, 4)
#1 {main}
thrown in /in/mc4XU on line 4
Process exited with code 255.
But I expected this output instead:
pretty much anything except saying it needs a third argument that isn't documented.
PHP Version
PHP 8+
Operating System
Linux 5.4.0-88-generic # 99-Ubuntu SMP Thu Sep 23 17:29:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[edit] idk it says i added those tags (bugs, triage) but they showed up on their own i just report the news
Activity
damianwadley commentedon Aug 24, 2022
So there's two bugs here:
Notice the other syntax:
Internally, class methods look a lot like regular functions that happen to take the "this" object as the first argument, and the procedural syntax for
numfmt_formatintentionally mirrors that fact. So when it says argument 3 it does mean the$typeand it's not noticing that you used the OOP syntax.Given this procedural/OOP stuff is a common setup, I assume this "is it argument 2 or 3?" problem has a standard solution.
TYPE_CURRENCYisn't supported.This is likely deliberate because there's a
formatCurrencymethod available. It takes a special$currencyargument so that functionality can't simply be added toformat.IMO this needs two fixes: one that PHP detects
TYPE_CURRENCYand then tells you that you need to useformatCurrencyinstead, then another for the docs.bobmagicii commentedon Aug 25, 2022
glad someone agrees that something is amiss. both of the proposed fixes sound like the correct direction.
just for full vision the reason i did what i did the way i did, was it seemed like numberformatter could be told to init with a locale and desired formatting. and indeed i noticed the formatCurrency method, and more specifically, that the format method took a type.
this suggested to me that i should initialise one numberformatter global to my app instance, using the user's preferences, and for consistency sake across all my various calls, i elected to only use
formatwith type currency so that it looked like all the other calls to format this and that and those. the final assumption i made was that numberformatter as en_US would default to USD, which would then makeformat(value, CURRENCY), seem reasonable.cmb69 commentedon Aug 25, 2022
It seems so far it has not. In theory it could be done by modifying the
zend_argument*error()functions, but that would be a BC break, since external extensions may already cater to that, like for example,transliterator_transliterate():php-src/ext/intl/transliterator/transliterator_methods.c
Line 321 in cbb024c
So we likely need to handle the individual calls.
I would go with a doc fix only, but given that it is documented to support any
TYPE_*, an explicit error message may be reasonable.NumberFormatter::format() does not support ::TYPE_CURRENCY
NumberFormatter::format() does not support ::TYPE_CURRENCY
Fix phpGH-9421 Incorrect argument number for ValueError in NumberForm…
Fix phpGH-9421 Incorrect argument number for ValueError in NumberForm…
Fix GH-9421 Incorrect argument number for ValueError in NumberFormatter
NumberFormatter::format() does not support ::TYPE_CURRENCY
NumberFormatter::format() does not support ::TYPE_CURRENCY