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
