it-swarm.com.de

Wann fange ich Java.lang.Error?

In welchen Situationen sollte man Java.lang.Error bei einer Bewerbung?

108
João

Im Allgemeinen niemals. Manchmal müssen Sie jedoch bestimmte Fehler abfangen.

Wenn Sie Framework-ish-Code schreiben (Laden von Klassen von Drittanbietern), ist es möglicherweise ratsam, LinkageErrors abzufangen (keine Klassendef. Gefunden, unbefriedigter Link, inkompatibler Klassenwechsel). Ich habe auch einige dumme Drittanbieter-Codes gesehen, die Unterklassen von Fehlern auslösen, daher müssen Sie auch diese behandeln.

Ich bin mir übrigens nicht sicher, ob es nicht möglich ist, OutOfMemory wiederherzustellen.

96
Yoni Roit

Noch nie. Sie können nie sicher sein, dass die Anwendung die nächste Codezeile ausführen kann. Wenn Sie ein OutOfMemoryError erhalten, haben Sie keine Garantie, dass Sie zuverlässig etwas tun können . RuntimeException abfangen und Ausnahmen prüfen, aber niemals Fehler.

http://pmd.sourceforge.net/rules/strictexception.html

50
tronda

Im Allgemeinen sollten Sie immer Java.lang.Error Abfangen und in ein Protokoll schreiben oder dem Benutzer anzeigen. Ich arbeite im Support und sehe täglich, dass Programmierer nicht sagen können, was in einem Programm passiert ist.

Wenn Sie einen Daemon-Thread haben, müssen Sie verhindern, dass dieser beendet wird. In anderen Fällen funktioniert Ihre Anwendung ordnungsgemäß.

Sie sollten nur Java.lang.Error Auf höchster Ebene fangen.

Wenn Sie sich die Fehlerliste ansehen, werden Sie feststellen, dass die meisten Fehler behoben werden können. Beispielsweise wird beim Lesen beschädigter Zip-Dateien ein ZipError angezeigt.

Die häufigsten Fehler sind OutOfMemoryError und NoClassDefFoundError, bei denen es sich in den meisten Fällen um Laufzeitprobleme handelt.

Beispielsweise:

int length = Integer.parseInt(xyz);
byte[] buffer = new byte[length];

kann ein OutOfMemoryError erzeugen, ist aber ein Laufzeitproblem und kein Grund, Ihr Programm zu beenden.

NoClassDefFoundError treten meistens auf, wenn eine Bibliothek nicht vorhanden ist oder wenn Sie mit einer anderen Java Version) arbeiten. Wenn es ein optionaler Teil Ihres Programms ist, sollten Sie Ihr Programm nicht beenden.

Ich kann viele weitere Beispiele nennen, warum es eine gute Idee ist, Throwable auf der obersten Ebene abzufangen und eine hilfreiche Fehlermeldung zu erstellen.

16
Horcrux7

In Multithread-Umgebungen möchten Sie es am häufigsten abfangen! Wenn Sie es fangen, protokollieren Sie es und beenden Sie die gesamte Anwendung! Wenn Sie das nicht tun, ist ein Thread, der möglicherweise einen wichtigen Teil erledigt, tot, und der Rest der Anwendung wird denken, dass alles normal ist. Daraus können viele unerwünschte Situationen entstehen. Ein kleinstes Problem ist, dass Sie die Ursache des Problems nicht leicht finden können, wenn andere Threads einige Ausnahmen auslösen, weil ein Thread nicht funktioniert.

Zum Beispiel sollte die Schleife normalerweise sein:

try {
   while (shouldRun()) {
       doSomething();
   }
}
catch (Throwable t) {
   log(t);
   stop();
   System.exit(1);
}

Sogar in einigen Fällen möchten Sie verschiedene Fehler unterschiedlich behandeln, zum Beispiel können Sie in OutOfMemoryError die Anwendung regelmäßig schließen (möglicherweise sogar Speicher freigeben und fortfahren), in anderen Fällen können Sie nicht viel tun.

14
Sarmun

Sehr selten.

Ich würde sagen, nur auf der obersten Ebene eines Threads, um zu versuchen, eine Nachricht mit dem Grund für einen Thread sterben auszugeben.

Wenn Sie sich in einem Framework befinden, das solche Aufgaben für Sie erledigt, überlassen Sie dies dem Framework.

8
Darron

Fast nie. Fehler sind Probleme, mit denen Anwendungen im Allgemeinen nichts anfangen können. Die einzige Ausnahme könnte sein, die Darstellung des Fehlers zu behandeln, aber auch das könnte je nach Fehler nicht wie geplant verlaufen.

6
nicerobot

Ein Error sollte normalerweise nicht gefangen werden , da es auf einen abnormalen Zustand hinweist, der niemals auftreten sollte auftreten .

Aus der Java API-Spezifikation für die Error -Klasse:

Ein Error ist eine Unterklasse von Throwable, die auf schwerwiegende Probleme hinweist, die eine vernünftige Anwendung nicht abfangen sollte. Die meisten dieser Fehler sind anormale Zustände. [...]

Eine Methode muss in ihrer throws-Klausel keine Unterklassen von Error deklarieren, die möglicherweise während der Ausführung der Methode ausgelöst, aber nicht abgefangen werden, da es sich bei diesen Fehlern um abnormale Bedingungen handelt, die niemals auftreten sollten.

Wie in der Spezifikation erwähnt, wird ein Error nur unter Umständen geworfen, unter denen es wahrscheinlich ist, dass die Anwendung beim Auftreten eines Error sehr wenig kann und unter bestimmten Umständen das Java Virtual Machine selbst befindet sich möglicherweise in einem instabilen Zustand (z. B. VirtualMachineError )

Obwohl ein Error eine Unterklasse von Throwable ist, bedeutet dies, dass es von einem try-catch-Klausel, wird aber wahrscheinlich nicht wirklich benötigt, da sich die Anwendung in einem abnormalen Zustand befindet, wenn eine Error von der JVM ausgelöst wird.

Es gibt auch einen kurzen Abschnitt zu diesem Thema in Abschnitt 11.5 Die Ausnahmehierarchie der Java Language Specification, 2nd Edition .

6
coobird

Wenn Sie verrückt genug sind, ein neues Unit-Test-Framework zu erstellen, muss Ihr Test-Runner wahrscheinlich Java.lang.AssertionError abfangen, das von Testfällen ausgelöst wird.

Ansonsten siehe andere Antworten.

6
noahlz

Und es gibt noch einige andere Fälle, in denen Sie, wenn Sie einen Fehler bemerken müssen ihn erneut werfen. Zum Beispiel: ThreadDeath sollte niemals abgefangen werden, da dies ein großes Problem darstellen kann, wenn Sie es in einer geschlossenen Umgebung (z. B. einem Anwendungsserver) abfangen:

Eine Anwendung sollte Instanzen dieser Klasse nur abfangen, wenn sie nach dem asynchronen Beenden bereinigen muss. Wenn ThreadDeath von einer Methode abgefangen wird, muss es erneut geworfen werden, damit der Thread tatsächlich abstirbt.

5
Guillaume

Sehr sehr selten.

Ich habe es nur für einen ganz bestimmten bekannten Fall getan. Beispielsweise könnte Java.lang.UnsatisfiedLinkError ausgelöst werden, wenn zwei Independence ClassLoader dieselbe DLL laden. (Ich bin damit einverstanden, dass ich die JAR auf einen gemeinsam genutzten Classloader verschieben soll.)

Am häufigsten ist es jedoch, dass Sie sich anmelden müssen, um zu wissen, was passiert ist, wenn sich Benutzer beschweren. Sie möchten, dass eine Nachricht oder ein Popup an den Benutzer gesendet wird, und dann im Hintergrund nicht mehr.

Sogar Programmierer in C/C++ zeigen einen Fehler an und sagen etwas, was die Leute nicht verstehen, bevor er beendet wird (z. B. Speicherfehler).

4
Dennis C

es ist ziemlich praktisch, Java.lang.AssertionError in einer Testumgebung abzufangen ...

3
Jono

In einer Android Anwendung fange ich ein Java.lang.VerifyError . Eine Bibliothek, die ich verwende, funktioniert nicht auf Geräten mit einer alten Version des Betriebssystems und Der Bibliothekscode wird einen solchen Fehler auslösen. Ich könnte den Fehler natürlich vermeiden, indem ich die Version des Betriebssystems zur Laufzeit überprüfe, aber:

  • Das älteste unterstützte SDK wird möglicherweise in Zukunft für die jeweilige Bibliothek geändert
  • Der Try-Catch-Fehlerblock ist Teil eines größeren Rückfallmechanismus. Einige bestimmte Geräte, obwohl sie die Bibliothek unterstützen sollen, lösen Ausnahmen aus. Ich fange VerifyError und alle Ausnahmen ab, um eine Ausweichlösung zu verwenden.
3
kgiannakakis

Idealerweise sollten wir keine Fehler behandeln/abfangen. Es kann jedoch Fälle geben, in denen wir dies tun müssen, je nach den Anforderungen des Frameworks oder der Anwendung. Angenommen, ich habe einen XML-Parser-Daemon, der DOM-Parser implementiert, wodurch mehr Speicher belegt wird. Wenn es eine Anforderung gibt, wie Parser, sollte der Thread nicht gestorben sein, wenn er OutOfMemoryError erhält, sondern er sollte damit umgehen und eine Nachricht/Mail an den Administrator der Anwendung/des Frameworks senden.

2
user3510364

Es liegt ein Fehler vor, wenn die JVM nicht mehr wie erwartet funktioniert oder kurz davor steht. Wenn Sie einen Fehler abfangen, gibt es keine Garantie dafür, dass der catch-Block ausgeführt wird, und noch weniger, dass er bis zum Ende ausgeführt wird.

Es hängt auch vom laufenden Computer und dem aktuellen Speicherstatus ab, sodass Sie nicht testen, versuchen und Ihr Bestes geben können. Sie werden nur ein gefährliches Ergebnis haben.

Sie werden auch die Lesbarkeit Ihres Codes herabstufen.

1
Nicolas Zozol

im Idealfall sollten wir niemals Fehler in unserer Java) - Anwendung abfangen, da dies ein anormaler Zustand ist. Die Anwendung würde sich in einem anormalen Zustand befinden und könnte zu Autoshing führen oder ein ernsthaft falsches Ergebnis liefern.

1
Vivek

Es kann angebracht sein, Fehler in Komponententests abzufangen, die überprüfen, ob eine Behauptung vorliegt. Wenn jemand Behauptungen deaktiviert oder auf andere Weise löscht, möchten Sie dies wissen

1
Chanoch