optional feature with contract inheritance? (design question)

[Lutger]

Jonathan M Davis wrote:
...
> 
> Generally, I speaking, I think that having functions which override
> functions from a base class and throw if they're used is a bad design. It
> may be that it makes perfect sense in some contexts, but generally, I'd
> consider it a very bad idea. Personally, I hate it when APIs do that.

I agree, but it's sometimes hard to avoid. For example if you want a 
composite and component class to have a common interface, some operations 
won't make sense for components. The alternative to throwing is a no-op or 
return a null object. Or asserting.  
 
> Regardless of whether you consider that a good or bad idea though, there's
> no point in adding contracts into it. They don't add anything. If the
> feature is supported by the class, then no exception gets thrown. If it
> isn't, then an exception gets thrown. All adding asserts in preconditions
> does is make it an AssertError instead of whatever kind of exception you're
> throwing in the body. It doesn't add anything.
> 
> - Jonathan M Davis

True, it only adds AssertError and that could be replaced with regular 
asserts.

Thanks.