# Adding `class UnsupportedOperationException extends RuntimeException` to php? - Thread: https://externals.io/message/117022 - Original archive: https://news-web.php.net/php.internals/117022 - Started by tyson andre on 2022-02-13T15:50:37+00:00 - Messages: 3 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #117022 — tyson andre — 2022-02-13T15:50:37+00:00 URL: https://externals.io/message/117022#117022 Hi internals, Currently, there doesn't seem to be an exact fit for indicating that a method isn't supported on an object by design (and will throw unconditionally). (For example, when implementing an interface or overriding a base class, e.g. an Immutable datastructure not implementing offsetSet/offsetUnset, an object that does not support serialization and overrides __serialize/__unserialize to forbid it, etc.) - BadMethodCallException - Exception thrown if a callback refers to an undefined method or if some arguments are missing. - DomainException/RangeException - Seemingly refer to argument values - LogicException - "Exception that represents error in the program logic. This kind of exception should lead directly to a fix in your code." I don't believe it's quite that, because code designed for the interface implementing the method (e.g. ArrayAccess) might have correct logic, it's the choice of implementation/subclass at runtime that caused the exception. - RuntimeException and its subclasses are also used for unpredictable errors such as missing files, network/db errors, etc, making the meaning of `try { ... } catch (RuntimeException $e) {}` less clear. - BadMethodCallException - Exception thrown if a callback refers to an undefined method or if some arguments are missing.' seems misleading as well since the method is defined and has its arguments, and existing uses in CachingIterator/Phar are checking the object's properties or arguments. (Uncaught BadMethodCallException: CachingIterator does not fetch string value (see CachingIterator::__construct) in %s:%d) RuntimeException (or a userland subclass) is the most common exception type I see used for this purpose, but RuntimeException is already used for many other things and has many subclasses. https://www.php.net/manual/en/spl.exceptions.php#spl.exceptions.tree https://www.php.net/manual/en/class.exception.php (RuntimeException and subclasses are also used for unpredictable errors such as missing files, network/db errors, some types of errors in destructors, etc, making writing `try { ... } catch (RuntimeException $e) {}` to catch this also catch other issues that should instead be rethrown.) It would be useful to provide this instead of having extensions or userland code throw RuntimeException or implement their own exceptions https://www.php.net/manual/en/class.solrillegaloperationexception IDEs/type checkers would also have more information to indicate that a method call is probably invalid in a use case and it would allow userland code to be have more specific api documentation/type info than `@throws RuntimeException` (rather than deliberately invoking a shared helper method to throw exceptions). - Type checkers already check this - e.g. https://psalm.dev/docs/running_psalm/configuration/#ignoreexceptions https://github.com/phan/phan/wiki/Issue-Types-Caught-by-Phan#phanthrowcommentintostring Thoughts on adding UnsupportedOperationException to the spl? Thanks, Tyson --- ## #117120 — duesterhus@woltlab.com — 2022-02-23T13:41:48+00:00 URL: https://externals.io/message/117022#117120 · In reply to: #117022 Hi Tyson > Currently, there doesn't seem to be an exact fit for indicating that a method isn't supported on an object by design (and will throw unconditionally). > (For example, when implementing an interface or overriding a base class, e.g. an Immutable datastructure not implementing offsetSet/offsetUnset, > an object that does not support serialization and overrides __serialize/__unserialize to forbid it, etc.) > > […] > > Thoughts on adding UnsupportedOperationException to the spl? > The "Redacting parameters in back traces" RFC has the same issue for the SensitiveParameterValue::__unserialize() method [1] which is not supported by design. In userland I'd commonly use BadMethodCallException for this purpose, but thinking about it: A `LogicException` is not really fitting for the reasons you outlined. UnsupportedOperationException sounds like a useful addition to me. [1] https://wiki.php.net/rfc/redact_parameters_in_back_traces#choice_of_replacement_value Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duesterhus@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P --- ## #117230 — Jordan LeDoux — 2022-03-02T23:48:49+00:00 URL: https://externals.io/message/117022#117230 · In reply to: #117120 On Wed, Feb 23, 2022 at 5:42 AM Tim Düsterhus, WoltLab GmbH < duesterhus@woltlab.com> wrote: > Hi Tyson > > > > […] > method isn't supported on an object by design (and will throw > unconditionally). > > […] > e.g. an Immutable datastructure not implementing offsetSet/offsetUnset, > > […] > __serialize/__unserialize to forbid it, etc.) > > […] > > The "Redacting parameters in back traces" RFC has the same issue for the > SensitiveParameterValue::__unserialize() method [1] which is not > supported by design. > > In userland I'd commonly use BadMethodCallException for this purpose, > but thinking about it: A `LogicException` is not really fitting for the > reasons you outlined. > > UnsupportedOperationException sounds like a useful addition to me. > > I like this idea, however I think something other than 'Operation' should be used. Perhaps it is due to all the work on my recent RFC, but to an 'Operation' implies an 'Operator'. -Jordan