Designfrage: Exceptions in Konstruktoren

[Gast2]

Hi,
ich implementier hier grad einen Graphen und bin am Überlegen wie man folgende Situation am besten lösen könnte:

Ich habe diese drei Konstruktoren:

    public DirectedGraph(ArrayList<Node> nodes, ArrayList<Edge> edge) throws IllegalNodeException, IllegalEdgeException {
        /* check nodes and edges */
    }

    public DirectedGraph(ArrayList<Node> nodes) throws IllegalNodeException, IllegalEdgeException {
        this(nodes, new ArrayList<Edge>());
    }

    public DirectedGraph() throws IllegalNodeException, IllegalEdgeException {
        this(new ArrayList<Node>(), new ArrayList<Edge>());
    }

Im obersten Kontruktor prüfe ich dann noch ob die Übergebenen Knoten und Kanten gültig sind, z.b. ob kein Knoten doppelt übergeben wird, ob alle Kanten End und Anfangspunkte vorhanden sind, ob sich negativ zyklische Graphen bilden etc.
Ich möchte gerne vermeiden, dass jeder Konstruktor 2 Exceptios "werfen kann". Der zweite Konstruktor würde ohne IllegalEdgeException und der dritte komplette ohne Exceptions auskommen.

Wie kann ich das geschickter machen?

 

[faetzminator]

Von [c]RuntimeException[/c] erben, Checked Exceptions sind irgendwie... komisch.
Ansonsten die Exception selbst fangen oder pro Konstruktor die jeweiligen Methoden selber aufrufen. Dabei kann natürlich [c]DirectedGraph(ArrayList<Node>, ArrayList<Node>)[/c] direkt [c]DirectedGraph(ArrayList<Node>)[/c] verwenden. In jedem Konstruktor einen Check machen. Du solltest lieber [c]List<Node>[/c] verwenden.

 

[Gast2]

Ich hab meine Exceptions jetzt von RuntimeException erben lassen, das war nen guter Tipp, danke.

 

[FArt]

Ich hab meine Exceptions jetzt von RuntimeException erben lassen, das war nen guter Tipp, danke.

Das finde ich nicht, zumindest nicht ohne tieferes Wissen zu dem Kontext, in dem der Code verwendet wird und mit der Begründung "checked exceptions sind irgendwie komisch".

Deklarierte Exceptions sind wichtig, wenn der Benutzer darauf reagieren können muss. Das ganze zwingend über RuntimeExceptions abzufackeln, weil der Code schöner aussieht ist ganz schlecht. Im Endeffekt wird der Benutzer trotzdem die (Runtime)Exceptions fangen und behandeln müssen. Ist das nicht der Fall, sind eigene Exceptions (vor allem verschiedene Exceptions) ein Antipattern. Eine IllegalStateException oder IllegalArgumentException wäre dann besser und diese wären sogar RuntimeExceptions.

Ob hier eigene deklarierte Exceptions gut oder schlecht sind lässt sich nur anhand dieses Codes nicht sagen.

Tipp: Exception-Handling Antipatterns | Java.net

 

[bygones]

Im Endeffekt wird der Benutzer trotzdem die (Runtime)Exceptions fangen und behandeln müssen.

die Frage ist eher KANN sich der Verwender um die exception kuemmern.

Falls der Verwender sie unnoetig behandeln muss ist eine RuntimeException weit besser, in diesem Fall MUSS er sie aber nicht behandeln.

Falls der Verwender dies aber kann oder sogar muss / soll, so kann hier auch checked Exception genutzt werden, wobei auch hier zu überprüfen ist ob eine unchecked nicht dennoch besser waere.

Allgemein sind Exceptions ein heisses Diskussionsthema

 

[Wortraum]

Sofern nicht wirklich, wirklich eigene Ausnahmen benötigt werden, hätte ich hier auch IllegalArgumentException geworfen.

 

[maki]

Sofern nicht wirklich, wirklich eigene Ausnahmen benötigt werden, hätte ich hier auch IllegalArgumentException geworfen.

Meistens braucht man keine eigenen Exception 😉

 

[Wortraum]

Meistens braucht man keine eigenen Exception 😉

Das versuchte ich mit „wirklich, wirklich“ zu betonen. 😉