Map's exception handling

Question

Does anyone have an idea why Map's contract for the get method says that when there exists no mapping for the given key, a null is returned (sentinel value) as opposed to an exception being thrown.
This causes me to call containsKey to determine if the returned null is an error value and a mapped one.

Answer 1

Now, the difference between is
in constant factor rather than algorithmic complexity,
but some people get rather worried about efficiency.I understand that in general I shouldn't directly count the number of operations of an algorithm, but instead look at its overall time complexity. If an extra operation contributing to the constant factor makes the API easier to use then so be it. However, I am often tempted, believing that they will make a major difference, to perform some "optimizations".
It would't hurt for Collections.binarySearch, for example, to also return a pointer (via ListIterator) so that linked-list based Lists could use it to insert an element into a sorted List. As it is, two independent traversals have to be made (finding the index and then traversing to it). Complexity for both ways is the same but the one that returns a pointer seems more natural to me. Perhaps I'm trying to perform two things in one method.
public V get(K key)
Object get = super.get(key);
return get == null ? (super.containsKey(key) ?
) ? null : NO_MAPPING) : get;
}That's what I thought I'd do but then i remembered generics. I'm not to keen on them yet, but assuming NO_MAPPING is defined as above and V is some subtype of Object, the above code won't compile, right?
The reason why I ask all this is that I am indeed writing a wrapper of HashMap (which does not implement Map) and are looking for an elegant way to handle the not-found error inside my get function.