Try/catch über ganze Klasse

[Fohnbit]

Hallo,

besteht die Möglichkeit, eine Klasse komplett in einen Try/Catch Block zu setzen?
Damit ich bei ersten Tests nicht jede Methode extra einen Try Block erstellen muss.

Danke!

 

[kneitzel]

Das geht nicht und im Augenblick sehe ich da auch recht wenig Sinn drin, da die Behandlung der Exception doch von Aktion zu Aktion anders sein dürfte.

Wenn in der Klasse keinerlei Behandlung von Exceptions gewünscht ist, dann lass es weg und dann muss die nächst höhere Ebene sich darum kümmern.

 

[Saheeda]

Eine komplette Klasse in ein try-catch zu packen (sofern das möglich wäre) riecht stark nach Designfehler. Eine Exception sollte möglichst nah am Ort ihres Ursprung behandelt werden, ein try über ~ 400 Zeilen macht es nahezu unmöglich, die genaue Fehlerquelle einzugrenzen und mit einer vernünftigen Fehlermeldung zu behandeln. Viel mehr als "ups, geht net", wirst du dem Nutzer so nicht mitteilen können. Fehlermeldungen sollten aber ne gewisse Aussagekraft haben, z.B. "Speichern nicht möglich, da die Datenbankverbindung falsch ist." oder "Gesuchte Datei existiert nicht."

 

[JStein52]

Ich hatte den TE so verstanden dass er mal schnell was ausprobieren will und dabei will er nicht von Exceptions gestört werden denn die interessieren ihn dabei überhaupt nicht. Also sowas wie "ignoriere alle Exceptions, darum kümmere ich mich später"

 

[Saheeda]

@JStein52
Auch zum "nur mal kurz Probieren" würde ich mir sowas gar nicht erst angewöhnen, das greift sonst ganz schnell auf echten Code über. Macht ja die Tests so schön grün. Zumal ne Exception ja heißt, dass irgendetwas nicht funktioniert. Wenn mir aber egal ist, obs geht oder nicht, brauch ichs gar nicht erst probieren.

 

[JStein52]

Auch zum "nur mal kurz Probieren" würde ich mir sowas gar nicht erst angewöhnen

Ja, du hast ja auch recht ! Ich wollte nur deine Bemerkung mit Designfehler ein bisschen relativieren. Es ging glaube ich nicht darum generell Exceptions wegzulassen oder zu sparen oder so was. Er will mal kurz einen Codeschnipsel ausprobieren und weiss genau dass dafür die Datei die er einlesen will auch da ist. Und deshalb will er diese Exception erst mal "ausblenden ". Ist nur so eine Vermutung. ... Aber im allgemeinen hast du natürlich recht.

 

[kneitzel]

Designfehler ist evtl. falsch gewählt. Statt dessen ist es evtl. ein falsches Vorgehen. Hier wäre wichtig zu verstehen, was das eigentliche Anliegen ist.

a) Stört es den TE, dass er sich beim Schreiben von Code um gewisse Exceptions zu kümmern hat? Damit Code compiliert, müssen manche Exceptions behandelt werden oder die Funktion muss diese auch nach außen weiter geben.

Hier ist in meinen Augen wichtig, dass man immer relativ sauberen Code schreiben muss und dazu gehört halt ein behandeln der wichtigsten Exceptions. Die Gefahr ist hier in meinen Augen einfach gegeben, dass man mal eben schnell etwas ausprobiert und dann wird es komplett oder teilweise in den eigentlichen "produktiven" Code übernommen.

b) Evtl. stört es den TE, dass er mehrere Dinge testen will. Bei seinem ersten Test gibt es dann so eine Exception und die anderen Tests laufen nicht mehr. Ich habe hier jetzt bewusst von testen und nicht von probieren geschrieben. Hier wäre die Lösung, einfach separate Tests zu schreiben. Die kann er dann alle zusammen laufen lassen und dann bekommt er klare Ergebnisse a.la. Test 1 gab es eine Exception, Test 2 und 3 waren ok, Test 4 war ein Assert falsch und beim Test 5 gab es wieder eine Exception.
Sprich: Hier bietet sich ggf. die Nutzung von Test-Frameworks an. (Man mag da zustehen, wie man will - ich probiere vieles z.B. direkt in Unit Tests aus. Es ist trivial eine neue Klasse mit Unit-Tests zu erstellen und darin dann die Tests durchzuführen. Ggf. werden dann darauf Unit-Tests die bleiben oder ich schmeisse die Datei am Ende weg (Undo Pending Changes und winke winke sind die Tests erledigt und weg). Meistens ist es dann am Ende aber tatsächlich so, dass die Unit-Tests am Ende bleiben. Werden dann lediglich umgeschrieben so dass die nicht mehr die eigentliche Logik enthalten sondern eben die Logik aus anderen Klassen aufrufen und per Asserts die Ergebnisse prüfen.

Vieles ist somit wohl eine Frage der Vorgehensweise. Dabei ist in der Vorgehensweise auch keinerlei Wertung zu sehen! Gewisse Vorgehen mögen prinzipiell gut und sinnvoll sein (für spezielle Zielgruppen und in speziellen Szenarien) nur eben werden die durch die vorhandenen Tools nicht unterstützt, so dass man sich überlegen sollte, ob man auf Grund der Tools nicht anders vorgehen möchte.

Somit möchte ich nur alternative Vorgehen anbieten / vorschlagen ohne jegliche Wertung!

 

[Fohnbit]

Hallo,

gerne erkläre ich den Hintergrund genauer.

Ich schreibe kleine Plugins für ein OSGi System. Sehr viele Methoden werden nicht durch mich aufgerufen.

Um nun beim testen eventuelle Fehler zu erkennen, MUSS ich in jeder Methode eine try/catch Block einfügen.

Ich dachte, ich kann vielleicht irgendwie Methoden übergreifend mit einem try/catch Block absichern.

Es soll natürlich eine exakte und genaue Fehlerausgabe erfolgen. Aber mit PrintStack() hatte ich immer auf die Zeile genau das Problem gefunden.

Also statt:

@Override
    public void methode1() {
try{}catch{}
}

@Override
    public void methode1o() {
try/catch
}
@Override
    public void methode2() {
try{}catch{}
}

@Override
    public void methode3() {
try{}catch{}
}

Pseudomässig so:

try{
@Override
methode1()

@Override
methode2()

@Override
methode3()
catch{}

Somit habe ich für alle Methode nur eine try/catch Block und muss nicht in 50 Methoden jeweils einen eigenen try/catch Block einfügen.

Der Aufwand ist zwar überschaubar, aber es interessiert mich generell ob statt 50 Anweisungen ich es mit einer schaffen könnte.

Oder kann man eine class global mit einem try/catch absichern?

 

[kneitzel]

Also evtl. hilft Dir ja AOP (Aspect oriented programing). AspectJ könntest Du Dir z.B. ansehen. Das ist meines Wissens einer der am meisten benutzten Bibliotheken wobei es auch andere Lösungen für AOP gibt.

Und da gäbe es dann z.B. den after-throwing advice.

Die Idee hinter AOP ist eben genau so ein Szenario: Es soll doppelter Code vermieden werden, der so an vielen Stellen auftritt. Da gibt es leider von Java aus keine Methodik so dass diese Aspekte eingeführt wurden.

Evtl. lohnt es sich für Dich, dich da einmal einzulesen?

 

[thecain]

3 Möglichkeiten:

1. Wenn du Zugriff auf die Methode hast, welche die Exception wirft, könntest du sie in eine unchecked Exception umwandeln

2. Den Methodensignaturen ein throws Exception anhängen.

3. Den Aufruf der die Exception wirft in eine eigene private Methode wrappen und dort die Exception einmal catchen. dann im eigentlichen Code nur noch deine Methode verwenden.