Implementieren einer Schnittstelle (Interface), Ausnahmen

[citizen_erased]

ich implementiere die Schnittstelle List für eine eigene Klasse. ich muss also alle geforderten methoden mit codeanweisungen füllen, damit der compiler sagt: alles supi!

wie ist es mit den ausnahmen?
bei der methode addAll(int index, Collection collection) z.b. heisst es in der api
...
IllegalArgumentException - if some aspect of one of elements of the specified collection prevents it from being added to this list.

wie bindend ist diese "vorgabe". was ist, wenn ich hier eine andere ausnahme werfe? der compiler meckert zwar nicht, aber ich kann mir denken, dass jemand anderes hier nicht meine SuperSpecialException erwartet, sondern eine IllegalArgumentException auffangen will.

 

[bygones]

wie bindend ist diese "vorgabe". was ist, wenn ich hier eine andere ausnahme werfe? der compiler meckert zwar nicht, aber ich kann mir denken, dass jemand anderes hier nicht meine SuperSpecialException erwartet, sondern eine IllegalArgumentException auffangen will.

Wenn du ein Interface implementieren willst müssen alle definitionen eingehalten werden (sonst wäre ja der Sinn eines Interfaces ad absurdum geführt), d.h. wenn du eine andere Exception in einer Methode wirfst so müsste der Compiler eigentlich meckern, da deine Implementierung nicht mit der Definition übereinstimmt (z.B. Eclipse lässt das nicht zu !).

Du kannst aber alle Exception verwenden die von RuntimeException abstammen (wenn du in die API schaust siehst du, dass alle Exception von addAll von dieser Oberklasse abstammen !). D.h. wenn du eine eigene Exception hast muss die von RuntimeException abgeleitet sein und es klappt !

 

[citizen_erased]

ich meine die situationen, in der die ausnahme nicht zur signatur der methode gehört.
damit wir vom selben (gleich?? shit) reden:

public void doIt()
public void doIt() throws DoneNothingException

würde ich als zwei methoden mit unterschiedlichen signaturen bezeichnen.

aus der List-API

public boolean containsAll(Collection c)
...
Throws:
ClassCastException - if the types of one or more elements in the specified collection are incompatible with this list (optional).
NullPointerException - if the specified collection contains one or more null elements and this list does not support null elements (optional).
NullPointerException - if the specified collection is null.

ich sehe das so:
kein compiler wird verlangen, dass ich den aufruf durch einen try-catch-block sichere, da die methode nicht verkündet, dass sie eine ausnahme weiterleiten würde. die in der api erwähnten ausnahmen können aber trotzdem auftreten, falls zur laufzeit entsprechende situationen vorliegen.
und hier stellt sich für mich die frage, ob ich statt einer NullPointerException auch eine andere ausnahme werfen kann.

 

[bygones]

ich meine die situationen, in der die ausnahme nicht zur signatur der methode gehört.
damit wir vom selben (gleich?? shit) reden:

public void doIt()
public void doIt() throws DoneNothingException

Du willst das also als zwei methoden in einer Klassen habe, da sie deiner Meinung nach versch. Signaturen haben ??

Das wird nicht gehen. Stell dir den aufruf vor:

new MeineClass().doIt();

Welche soll er aufrufen ??? Das sollte auch schon beim compilieren Probleme geben !

 

[citizen_erased]

du hast recht. throws-klausel gehört demnach nicht zur signatur.
aber der rest meiner frage ist nicht zu klären.

 

[bygones]

und hier stellt sich für mich die frage, ob ich statt einer NullPointerException auch eine andere ausnahme werfen kann.

Meinst du das ?
Das habe ich oben erwähnt. Die Methode kann jede Exception werfen, die von der Klasse RuntimeException erbt. D.h. du kannst auch deine eigene Exception werfen lassen !

 

[citizen_erased]

hmm.. ich konnte wohl eins und eins nicht zusammen zählen.
man kann also sagen: alle fehler, die zur laufzeit auftreten, können eine von RuntimeException abgeleitete ausnahme verursachen. diese wird von der methode nicht angekündigt.
diese können (oder eben auch nicht) geworfen werden und zusätzlich weitere ausnahmen, die von RuntimeException abgeleitetet werden, wa?

ok. vielen dank!

 

[bygones]

Ja :idea: