Re: Adding `class UnsupportedOperationException extends RuntimeException` to php?
| From: | Tim Düsterhus, WoltLab GmbH | Date: | Wed, 23 Feb 2022 13:41:48 +0000 |
| Subject: | Re: Adding `class UnsupportedOperationException extends RuntimeException` to php? | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117120@lists.php.net to get a copy of this message | ||
Hi Tyson
On 2/13/22 16:50, tyson andre wrote:
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