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
duester...@woltlab.com
www.woltlab.com
Managing director:
Marcel Werk
AG Potsdam HRB 26795 P
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
