Ich habe eine Single-Thread-App, die den DOS-Errorlevel auf etwas nicht Null setzen sollte, wenn ein Problem vorliegt. Ist es besser, eine RuntimeException zu werfen oder System.exit (ungleich Null) zu verwenden? Ich brauche den Stack-Trace nicht, und ich erwarte nicht, dass diese App erweitert/wiederverwendet wird. Was sind die Unterschiede zwischen diesen beiden Optionen?System.exit (num) oder eine RuntimeException von main werfen?
Werfen Sie keine Ausnahme, es sei denn, Sie haben wirklich eine außergewöhnliche Bedingung. System.exit(int) ist genau aus diesem Grund da. Benutze es.
EDIT: Ich denke, dass ich Ihre Frage falsch gelesen haben kann. Ich dachte, du fragst, wann du die JVM normal verlassen willst, aber signalisierst, dass etwas nicht richtig geht, ob es besser ist, eine Ausnahme zu werfen oder System.exit zu verwenden.
Wenn jedoch das Problem, das auftritt, etwas ist, das bereits durch eine Java-Ausnahme angezeigt wird, ist es in Ordnung, diese Ausnahme unbehandelt zu lassen. Sie müssen die Ausnahme nicht abfangen und System.exit anrufen.
Wenn Sie die Wahl haben, ob Sie eine Ausnahme auslösen oder System.exit anrufen, denken Sie darüber nach, ob die Fehlerbedingung möglicherweise durch Java-Code verursacht wird, der Ihre Methode aufruft. Wenn der Fehler direkt in der main Methode auftritt, wird es wahrscheinlich nie einen Aufrufer geben, um die Ausnahme zu behandeln, so dass Sie wahrscheinlich System.exit aufrufen sollten. Andernfalls ist es im Allgemeinen am besten, eine Ausnahme auszulösen - aber nicht RuntimeException, Sie sollten wahrscheinlich einen Ausnahmetyp verwenden, der den aufgetretenen Fehler angemessen darstellt. Schreiben Sie bei Bedarf eine eigene Unterklasse von RuntimeException.
Warum setzen Exceptions von main den errorlevel? Es scheint, dass sie aus irgendeinem Grund dort sind. – VarV
Wenn eine Anwendung nicht erfolgreich beendet wird, sollte der Rückkehrcode von 0 verschieden sein. Daher wird die JVM den Rückkehrcode automatisch auf 1 setzen, wenn eine unbehandelte Ausnahme vorliegt, damit der übergeordnete Prozess erkennt, dass Ihr Programm aufgrund eines abgebrochen wurde Fehler (und nicht nur weil es fertig ist zu arbeiten). –
System.exit() nicht empfohlen. Es beendet JVM.
Das Herunterfahren der JVM ist in diesem Fall OK, die Anwendung ist beendet, wenn ein Fehler aufgetreten ist. – VarV
Weder generische RuntimeException ist meiner Meinung nach empfohlen –
entweder system.exit (int) oder neue RuntimeException werfen, wird letzteres nicht als generische RuntimeException betrachtet? – VarV
Im Allgemeinen würde ich in dieser Situation alle Ausnahmen in meiner Hauptmethode behandeln, möglicherweise durch den Aufruf System.exit. Dies gibt Ihnen Flexibilität darüber, wo/ob/wie mit außergewöhnlichen Bedingungen umzugehen ist, während Sie immer noch die Notwendigkeit haben, mit einem Fehlercode zu enden. Insbesondere erhalten Sie die Kontrolle über den Rückgabecode und alle anderen Ausgaben, die Sie möglicherweise für den Benutzer generieren (Fehlermeldung, Stack-Trace usw.). Wenn Sie in main eine Ausnahme auslösen (oder eine Ausnahme zulassen), verlieren Sie dieses Steuerelement.
Zusammengefasst nennen System.exit nur in der Exception-Handler auf oberster Ebene:
static public void main() {
try {
runMyApp();
} catch (Exception e) {
System.exit(1);
}
}
Ich werde wahrscheinlich mit dieser Lösung gehen, aber ich fang aus den Gründen, warum System.exit gegenüber dem Auslösen einer Ausnahme von Haupt bevorzugt wird. – VarV
Eine Ausnahme aus dem Stack-Trace drucken geworfen wird, und wenn Sie das nicht benötigen, shoul Sie System.exit verwenden .
Beim Beenden können Sie den Benutzer mit einem Sytem.out informieren (ich nehme an, die App läuft nur in einer Commanline-Umgebung).
Sie sollten nur alle Fehler abfangen und die Fehler in einem separaten Protokoll protokollieren. Dadurch wird sichergestellt, dass der StackTrace beim Schließen des Terminals nicht für immer verloren geht. Werfen Sie einen Blick auf log4j für diesen Zweck, es ist wirklich einfach zu bedienen.
Ja, es ist nur in einer Befehlszeilenumgebung. Ich brauche den Stack-Trace nicht, da dies ein automatisierter Schritt in unserem Build-Prozess ist, der entweder erfolgreich ist oder fehlschlägt, so dass selbst Log4j übertrieben ist. – VarV
Dann gehen Sie für die system.exit Lösung. Es ist eine gute Lösung, besonders wenn Sie den Return-Code danach überprüfen. Auf diese Weise können Sie signalisieren, was mit verschiedenen Codes schief gelaufen ist, oder einfach System.exit (-1) wählen – Jes
Die APP selbst sollte System.exit verwenden. Es ist seine Schnittstelle mit der aufrufenden Umgebung (Skript). Jede interne Komponente sollte natürlich Exception verwenden. Wenn Sie es zusammen kann es das sein, sowohl of'em:
Application.main(...) {
parse(args);
check(...);
try {
MyObject o = ...;
o.doMyStuff();
} catch (Exception e) {
System.err.println("Oops, something went wrong!"); // by example, or use a logging framework! // anyway in a shell app System.in/out/err IS my interface with the outworld
System.exit(ERROR_CODE);
}
System.out.println("Worked!");
}
System.exit (num) ist keine gute Wahl, da seine Abschaltung JVM sowie auch tut es das schließlich laufen blockieren, wenn Sie nach Fangblock.
Werfen RuntimeException auch möglicherweise nicht die beste Option, kann Unterklasse wie bereits erwähnt, die app-spezifische Ausnahme ist eine bessere Option meiner Meinung nach sein. -Manish
Sie scheinen Ihre eigene Frage beantwortet zu haben. Wenn Sie einen DOS-Fehlercode einstellen müssen, müssen Sie System.exit (code) verwenden. Sie können das nicht mit einer Ausnahme machen. – EJP
Wenn ich eine RuntimeException von main sets errorlevel auf 3 lege, bin ich mir nicht sicher warum oder unter allen Umständen. – VarV