package java.lang; public class String { // Returns the index within this string of the // first occurrence of the specified character. int indexOf(int ch) { //... } // Returns the index within this string of the // first occurrence of the specified character, // starting at the specified index. int indexOf(int ch, int fromIndex) { //... } //... }
OverdraftAccount
IS-AN Account
means:
I can use an OverdraftAccount
where an Account
is called for.
OverdraftAccount
's interface
isn't compatible with Account
's.
OverdraftAccount
's violates
Account
's semantic contract.
OverdraftAccount
violates the semantic contract of
Account
, you can't be sure you can use an
OverdraftAccount
where an Account
is needed.
OverdraftAccount
violates the semantic
contract of Account
,OverdraftAccount
IS-NOT-ANAccount
.
CloneNotSupportedException
iterator
interface from java.util
:
package java.util; public interface Iterator { // Returns true if the iteration has more elements. boolean hasNext(); // Returns the next element of the iteration. Object next(); // Removes from the underlying collection the last // element removed by the iterator (optional // operation). void remove(); }
remove()
on an object that
doesn't support it?
You get an UnsupportedOperationException
remove()
could have been named, mightRemove()
remove()
for
me, without calling the method.
package java.util; public interface Iterator { // Returns true if the iteration has more elements. boolean hasNext(); // Returns the next element of the iteration. Object next(); } package java.util; public interface Removerator extends Iterator { // Removes from the underlying collection the last // element removed by the iterator void remove(); }
Removerator
means an Iterator
that can
remove elements from the underlying collection
UnsupportedOperationException
)?
This is the most controversial design decision in the whole API. Clearly, static (compile time) type checking is highly desirable, and is the norm in Java. We would have supported it if we believed it were feasible. Unfortunately, attempts to achieve this goal cause an explosion in the size of the interface hierarchy, and do not succeed in eliminating the need for runtime exceptions (though they reduce it substantially).
Doug Lea, who wrote a popular Java collections package that did reflect mutability distinctions in its interface hierarchy, no longer believes it is a viable approach, based on user experience with his collections package. In his words (from personal correspondence) "Much as it pains me to say it, strong static typing does not work for collection interfaces in Java."
...
When all was said and done, we felt that it was a sound engineering compromise to sidestep the whole [exploding interfaces] issue by providing a very small set of core interfaces that can throw a runtime exception.
UnsupportedOperationException
?
It was never our intention that programs should catch these exceptions: that's why they're unchecked (runtime) exceptions. They should only arise as a result of programming errors, in which case, your program will halt due to the uncaught exception.
Semantics answer the question: What's the full range of legal behavior for this method?