Hi CHU Zhaowei, Thank you for your explanation.
On Wed, Oct 21, 2026, at 14:42, CHU Zhaowei wrote: > 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
