Häufige Fehler bei der Ausnahmebehandlung

Eine Ausnahme ist eine Unterbrechung des normalen Ausführungsflusses eines Java-Programms (oder eines anderen Programms). Dieser Verstoß kann aufgrund einer Speicherzugriffsverletzung, einer Division durch Null, eines Initialisierungsproblems, der Ausführung eines unzulässigen Befehls oder eines anderen schwerwiegenden Fehlers auftreten. Java ist in der Lage, alle derartigen unerwünschten Szenarien problemlos zu bewältigen, aber wenn es darum geht, diese Java-Funktionen durch Entwickler zu nutzen, können mehrere Probleme auftreten. In diesem Artikel werde ich nicht diskutieren, wie die Ausnahmebehandlung in Java funktioniert. Ich gehe davon aus , dass der Leser bereits mit der Ausnahmehierarchie, den geprüften Ausnahmen , den ungeprüften Ausnahmen und den Laufzeitausnahmen vertraut ist . Hier besprechen wir die häufigsten Fehler, die Sie vermeiden sollten.

Stakeholder in Ausnahmen

Immer wenn der Ausführungsthread unterbrochen wird, müssen Informationen darüber an den Programmausführer zurückgegeben werden. Dieser Thread kann vom Bildschirm, von einer Batch-Aufgabe oder auf andere Weise gestartet werden. Alle diese Trigger warten auf einen Verstoß im Fluss, um eine Nachricht in einem bestimmten Format zu übertragen. Ein bildschirmbasierter Auslöser kann uns sanft darüber informieren, dass es technische Probleme gibt und wir uns an den Support wenden sollten, um Hilfe und Rat zu erhalten. Batch-Prozesse oder eigenständige Java-Programme erwarten möglicherweise, dass der Fehlerbericht in Form einer Art Protokoll erscheint, das für den Endbenutzer völlig unverständlich ist. Aber Geschäftsleute müssen Nachrichten in einer Sprache erhalten, die sie verstehen. Die gefürchtete NullPointerException in den Köpfen der Benutzer ist sehr ärgerlich. Manchmal sind diese Fehler eine Folge einer falschen Verwendung des Programms, manchmal handelt es sich jedoch um Probleme, die einer Korrektur bedürfen. Der zweite wichtige Akteur ist die Person, die sich mit den durch Ausnahmen aufgeworfenen Problemen befassen muss. Diese Person kann die tatsächliche Ausführung des Programms beim Auftreten der Ausnahme nicht beobachten. Es wird auf zwei Dingen basieren: erstens auf den Informationen des Benutzers, der das Problem hat, und zweitens auf einer Art Protokoll, das beim Auftreten einer Ausnahme erstellt wird. Darüber hinaus ist die Person, die das Problem analysiert, nicht dieselbe Person, die das Programm geschrieben hat, und daher muss der Programmentwickler genügend Informationen für die Analyse bereitstellen. Die einzige Kommunikationsmöglichkeit zwischen dem Programmentwickler und seinem Debugger ist ein Protokoll. Manchmal enthält das Protokoll aus Sicherheitsgründen auch nicht alle tatsächlichen Details der Programmausführung zum Zeitpunkt des Auftretens der Ausnahme. Schauen wir uns mögliche Fehler bei der Ausnahmebehandlung an. Einige von ihnen sehen ziemlich dumm aus, aber es gibt Leute. die ihnen erst dann Beachtung schenken, wenn diese Fehler zu Problemen führen.

Leerer Ausnahmeblock

Dies ist einer der unerwünschtesten Fehler bei der Ausnahmebehandlung. In diesem Fall wird die Ausnahme einfach ignoriert. Die Lösung enthält lediglich eine Kommentarzeile zum Verlassen der Ausnahme. try{ }catch(SQLException sqe){ // do nothing } In einigen seltenen Fällen, beispielsweise im letzten Block beim Herunterfahren der Datenbank, können Ausnahmen ausgelöst werden. In diesem Fall können sie ignoriert werden. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Falsche Verallgemeinerung der Ausnahmemeldung

Dieser Punkt ist subjektiv. Nachdem Sie die Ausnahme abgefangen haben, können Sie sie dem Endbenutzer in Form einer freundlichen Nachricht melden. Es ist durchaus möglich, dass die Details der ursprünglichen Nachricht verloren gehen, wenn die ursprünglichen Nachrichten in eine allgemeine Nachricht umgewandelt werden. Die Nachricht sollte dem Endbenutzer die richtigen Informationen übermitteln, sodass sich der Benutzer bei der Kontaktaufnahme mit dem Support-Team nur im entsprechenden Protokoll anmelden muss, um die Informationen bereitzustellen. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } In einer mehrschichtigen Anwendung fängt jede Schicht Ausnahmen ab und löst einen neuen Ausnahmetyp aus. Manchmal ist es unbedingt erforderlich, eine Ausnahme eines bestimmten Typs auszulösen: - Data Access Layer -> erstellt eine DataAccessException - Business Implementation Layer -> erstellt eine BusinessException - Application Service Layer -> erstellt eine ApplicationServiceException. Alles scheint logisch, nicht wahr? Hier müssen wir möglicherweise zwischen ApplicationServiceException und BusinessException wählen, da beide dieselben Informationen darstellen können. Eine dieser Ausnahmekonvertierungen erscheint unnötig.

Zerstören der StackTrace-Klasse

Während der Umwandlung einer Ausnahme in einen neuen Spezialtyp kann der Stack-Trace verschwinden, was die Suche nach der eigentlichen Ursache der Ausnahme zu einem Albtraum macht. Im folgenden Code können Sie sehen, wie eine neue Ausnahme ausgelöst wird, ohne Informationen von der ursprünglichen Ausnahme zu erhalten. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Der Ausnahmegrund wird überschrieben

Jede Ausnahmemeldung enthält Informationen über den Grund der Ausnahme. Wenn jedoch eine neue Ausnahme erstellt wird, werden Informationen über die alte möglicherweise dauerhaft gelöscht. Dies ähnelt dem obigen Beispiel, bei dem StackTrace möglicherweise entfernt wird, weil eine neue Ausnahme ausgelöst wird.

Kein Suchen nach bestimmten Ausnahmen

Manchmal gehen Entwickler bei der Behandlung von Ausnahmen gerne auf Nummer sicher. Manchmal ist das einfach. Das Abfangen von java.lang.Exception anstelle einer bestimmten Ausnahme ist jedoch nicht akzeptabel. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Unnötiges Fangen und Werfen

Fangen Sie Ausnahmen ab, wenn Sie sie in einen anderen Typ konvertieren möchten oder wenn es Ihnen hilft, der Ausnahmemeldung für den Endbenutzer oder Analysten einige Informationen hinzuzufügen. Andernfalls werfen Sie sie einfach weiter in der Methodensignatur weg (mithilfe von Würfen), anstatt sie abzufangen.

RuntimeException wird abgefangen

Ich würde empfehlen, das Abfangen von RuntimeException zu vermeiden. Stattdessen ist es besser, bestimmte Ausnahmen abzufangen und zu behandeln.

Ungeprüfte Ausnahmen finden

Es ist ein umstrittenes Thema, ob ungeprüfte Ausnahmen abgefangen werden sollen oder nicht. NullPointerException und ArrayIndexOutOfBound sind möglicherweise die besten Beispiele für ungeprüfte Ausnahmen. Anstatt diese Ausnahmen abzufangen, können Sie Ihren Code ändern, um diese Szenarien zu verarbeiten. Um beispielsweise NullPointerException zu vermeiden, sicherzustellen, dass alle Variablen initialisiert werden, um ArrayIndexOutOfBound-Ausnahmen zu vermeiden, um ein Array mit der richtigen Länge zu definieren usw.

Probleme im Zusammenhang mit der Ausnahmeprotokollierung

Das Magazin hilft der zweiten interessierten Person, also der Person, die das Problem analysiert. Manchmal übertreibt es ein Entwickler mit Protokolldateien und erstellt Protokolle auf jeder Ebene der Anwendung. Das Protokoll sollte die Ausnahme auf der Ebene aufzeichnen, auf der sie aufgetreten ist. Optimal erscheint es, eine Warnung anzuzeigen, dass eine Ausnahme aufgetreten ist, mit dem Vorschlag, die Ausführung des Programms zu stoppen oder fortzusetzen, und die obligatorische Protokollierung der Ausnahme im Protokoll.

Ausnahme bei der Flusskontrolle

Eine Ausnahme stellt eine Störung des normalen Programmablaufs dar, was bedeutet, dass Sie diesen Ablauf unterbrechen und den Endbenutzer darüber informieren müssen. Wenn wir einen Methodenaufruf hinzufügen, der ein alternativer Thread ist, führt dies zu großen Wartungsproblemen. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Allgegenwärtige Verwendung von java.lang.Exception

Es ist auch keine gute Idee, für jede Ausnahme überall java.lang.Exception zu verwenden. Stattdessen ist es besser, anwendungsspezifische Ausnahmen oder die am besten geeigneten Standard-Java-Ausnahmen zu verwenden. Originalartikel: Häufige Fehler bei der Ausnahmebehandlung. Übersetzt und gesprochen von: Ve4niY