ich kenne mich schon etwas in Java aus. Im Moment stolpere ich gerade über ein Update von Saxon-9.4 zu 9.8 bei der Implementierung der Methode javax.xml.transform.Transformer#setParameter . Die Klasse "javax.xml.transform.Transformer" ist ein Interface und Bestandteil der API. Die eigentlichen Implementierungen sind häufig von Drittherstellern. Java-Doc findet man hier: https://docs.oracle.com/javase/7/docs/api/javax/xml/transform/Transformer.html#setParameter(java.lang.String,%20java.lang.Object) Die Beschreibung für den Parameter "value" sagt: "The value object. This can be any valid Java object. It is up to the processor to provide the proper object coersion or to simply pass the object on for use in an extension." Es gibt eine Exception-Beschreibung "Throws: NullPointerException - If value is null." DIE EIGENTLICHE FRAGE; Kann man daraus schließen, dass bei Wert "null" JEDE Implementierung IMMER eine NullPointerException werfen MUSS (falls nicht, kann man dies als Bug ansehen), oder bedeutet dies nur, dass WENN die Implementierung null als Wert ablehnt, DANN muss sie dies mit einer NullPointerException tun? Es geht mir hierbei nicht im die Quirks bestimmter Implementierungen, sondern die Interpretation der offiziellen Java-Dokumente. Und ich will auch keinen Transformer bauen, sondern nur einen nutzen. Hier ist das Verhalten aber für unterschiedliche Versionen verschieden.
Gast
#5475612
Achim H. schrieb: > Es gibt eine Exception-Beschreibung > > "Throws: NullPointerException - If value is null." Es ist eindeutig beschrieben. null => Exception, keine Ausnahme von der Ausnahme
Gast
#5475799
Ich les das auch so wie Abradolf: Laut Dokumentation ist bei einer Übergabe von Null eine Exception zu erwarten. Freilich kann jemand, der das Interface implementiert hat, theoretisch davon abweichen, Null akzeptieren und irgendeinen Standardwert zurückliefern, also niemals eine Exception werfen. Damit bewegt er sich aber außerhalb der Spezifikation. Gerade wenn die Implementierung von Dritten kommt würde ich mich nicht unbedingt darauf verlassen daß die Exception wirklich in jeder Implementierung kommt, also z.B. Prüfungen darauf aufbauen und deren Ergebnisse ernsthaft nutzen. Wer weiß, wer die Doku da mißversteht bzw. das eher als entbehrliche Option ansieht. Ob man das schon als Bug ansehen kann weiß ich nicht, aber eine Abweichung von der Dokumentation ist es allemal.
Kleiner Nachklapp: An anderen Stellen wird in der Parameterbeschreibung explizit erwähnt, dass der Parameter nicht null sein soll. Das wäre also überflüssig?
Gast
#5476215
Achim H. schrieb: > Kleiner Nachklapp: An anderen Stellen wird in der Parameterbeschreibung > explizit erwähnt, dass der Parameter nicht null sein soll. Das wäre also > überflüssig? Das kommt darauf an, wie du entwickelst (Design by contract). Es gibt 2 Moeglichkeiten: - Der Aufrufer muss sicherstellen, dass der Parameter nicht null ist (Beispiel aus C: Functionen wie strcpy) - Der Aufgerufene muss sich um den Fall kuemmern, dass der Parameter null ist Wenn es da so steht, wie du sagst, dann muss der Aufrufer fuer die Korrektheit der Parameter sorgen. Trotzdem solltest du dir ueberlegen, was deine Funktion macht, wenn da doch mal ein null oder ein anderer ungueltiger Wert kommt. In C fuehrt sowas regelmaessig zu Bufferoverflows, Programmabstuertzen und Sicherheitsluecken.
Solange die Implementierung nicht überschrieben wird, gilt immer die Ableitung der Basis-Klasse.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |