On Wed, Feb 23, 2022 at 5:42 AM Tim Düsterhus, WoltLab GmbH < duester...@woltlab.com> wrote:
> 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. > > 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
