Hi
On 9/2/26 14:12, Rowan Tommins [IMSoP] wrote:
However, the policy Tim linked to lays out the details of how exceptions should be defined, and says the base should be \Exception, then something extension-specific, *not* any of the SPL exceptions.
The policy also specifies:
Newly introduced extensions MUST follow the following rules, existing extensions SHOULD follow the rules for newly introduced exceptions, but MAY diverge for consistency with existing symbols.
and with the base conversion functions being in ext/standard, the following also applies:
Symbols MUST NOT be namespaced under the Core, Standard or Spl namespaces. Instead, these extensions should be considered as a collection of different components (str_*, password_*), and SHOULD be namespaced according to these component names.
which then means that the following:
This is a slightly complex case, because there's no extension or obvious group of functions to name the base under.
is a relevant consideration: We are adjusting existing functionality in very narrowly scoped fashion and based on the recent improvements to the stdlib, it is not too unlikely that the existing functions are completely redesigned in the future, for example by introducing a new `int\` or `number\` namespace.
> Possibly a BaseConversionException?
With the above considerations and the policy’s requirement that:
The exception message MUST NOT be the only means of distinguishing exception causes that the user might want to handle differently.
and me coming up with at least two reasonable failure cases (parsing error and out of range / loss of precision), I would probably make this a conservative change and go with the plain `\Exception` exception directly. This intentionally does not make any promises and requires the user to use “narrow try blocks” to handle the exception, which is no worse the status quo.
Best regards
Tim Düsterhus