Wenn meine eigenen Datenstrukturen Implementierung, die eine vergleichbare Art erfordern ich immer so wie dies getan haben:Welche Vorteile hat es, Laufzeitausnahmen über Compile-Time-Prüfungen für Sammlungen zu werfen, die vergleichbare Typen erzwingen?
public class ComparableCollection<E extends Comparable<E>> { ... }
Das ist offensichtlich die vergleichbare Einschränkung erzwingt bei der Kompilierung. Aber ich war in den letzten paar Jahren ein Student und habe irgendwie übersehen, dass die Java-Implementierungen für Collections, die einen vergleichbaren Typ durchsetzen, dies nicht zur Kompilierungszeit tun, sondern zur Laufzeit, indem möglicherweise ein ClassCastException geworfen wird, während ein Element hinzugefügt wird; zB:
public class TreeSet<E> extends AbstractSet<E> implements NavigableSet<E>, ... { ... }
TreeSet wird von einem NavigableMap gesichert, die, wenn es Comparatornull ist, versucht, den Schlüssel zu werfen wie so:
Comparable<? super K> k = (Comparable<? super K>) key;
Nun, wenn der Typ isn eingeführt wird 't vergleichbar Ein ClassCastException wird geworfen.
Was sind die wirklichen Vorteile dieses Entwurfs gegenüber dem Erzwingen der Einschränkung zur Kompilierzeit?
Siehe auch http://stackoverflow.com/questions/13890542/creating-a-treeset-with-a-non-comparable-class-why-a-run-time-exception-rather. Elemente in einem TreeSet müssen nicht vergleichbar sein, Sie können explizit einen Komparator angeben. – Tunaki
@Tunaki, erstaunlich, wie etwas viel mehr Sinn macht, wenn man aus dem eigenen Kopf kommt. Das macht einfach zu viel Sinn. Einen Moment jetzt haben. – ChiefTwoPencils