[mrkeen]

What you lose is the ability to model objects based on the behaviours that they can perform.

I want to be able to design objects that have toString() and I want to be able to design objects that don't have toString().

The same goes for clone(), hash(), getPtr(), getEndian(), equals(), toBytes(), toJson(), encrypt(), delete(), isNumeric(), toXml(), serializationVersion() or compare().

[Bartweiss]

I suppose you could define toString() to throw an error, but obviously that's a messy hack in place of having that control. I can definitely appreciate the logic for making nothing intrinsic, and I can also see an argument for making equals() the only method of Object. (i.e. everything should have an identity function, but nothing more.)

Now I'm wondering... are there languages which formalize "implement with a throw" into some kind of explicit refusal to implement a method? Obviously there are method-sharing approaches other than inheritance, but I've never heard of "you must implement this, or explicitly choose not to".

[iudqnolq]

I'm not quite sure what you mean, but it's standard in python if you have a method in a class that must be subclassed and overridden you can have the default raise a NotImplementedError

[Bartweiss]

I was thinking about a condition that's specifically for "inherited but not supported", but that's pretty close to what I had in mind, yes.

Java doesn't have a language-level exception that's specifically for unusable methods, which can be a bit awkward. UnsupportedOperationException is the recommended answer, but it's relatively nonspecific as to why your operation wasn't supported. Apache's Commons extends that with NotImplementedException for cases where the call isn't definitionally impossible (e.g. adding to an unmodifiable map), but no implementation exists.