Warum gute Programmierer manchmal schweigend schlucken Ausnahmen?

Weil manchmal hat der Programmierer mehr wissen als der compiler.

E. g. (in einigen fiktionalen Sprache, wo die division durch null als Fehler):

try {
    x = 1 /(a*a + 1);
} catch (DivisionByZeroException ex) {
  //Cannot happen as a*a+1 is always positive
}

Da einige Sprachen (z.B. Java) benötigen, um zu fangen, einige/viele/alle Ausnahmen, die der compiler könnte sich darüber beschweren, während der Programmierer weiß, ist es nicht möglich. Manchmal ist der einzige Weg, um den compiler zu schweigen, ist ausdrücklich schlucken die Ausnahme.

In Sprachen, in denen der compiler sich nicht beschweren, die leeren catch-Regel ist nicht überhaupt geschrieben.

Edit: In der Praxis, möchte ich hinzufügen, ein assert(false) in den catch-block. Wenn theoretisch etwas passieren kann, es ist ein sehr ernstes problem, wenn es geschieht in der Praxis 😉

Edit2: Java erfordert nur fangen überprüft Ausnahmen. Sinngemäß meine Aussage ein bisschen.

Mir nur zwei Arten von Fällen, in denen ich geschluckt haben Ausnahmen.

1. Beim schließen von Dateien oder Datenbankverbindungen. Wenn ich einen Fehler erhalten, auf das schließen, was werde ich dagegen tun? Ich nehme an, ich sollte wirklich schreiben, die irgendeine Art von Fehlermeldung, aber wenn ich habe bereits erfolgreich die Daten Lesen, es scheint überflüssig. Es scheint auch, wie sehr im Gegensatz zu Ereignis-geschehen.

2. Mehr gerechtfertigt: Innerhalb der Fehlerbehandlung. Wenn ich nicht versuche zu schreiben der log-Datei, wo ich dabei bin, zu schreiben, den Fehler, der sagt, dass ich nicht schreiben konnte ist ein Fehler? In einigen Kontexten könnte man versuchen, auf dem Bildschirm schreiben, aber abhängig von der app, das könnte unmöglich sein, z.B. ein hintergrund-job mit kein Bildschirm, oder einfach nur verwirrend für die user die nicht in der Lage, irgendetwas zu tun, um den Fehler sowieso.

Einem anderen poster genannten Fällen, wo man weiß, die Ausnahme ist unmöglich, oder zumindest, dass es passieren würde es zu großen Problemen mit dem compiler oder Betriebssystem-Umgebung, wie es nicht zwei zahlen addiert richtig, in dem Fall, der sagt, die Ausnahme ist sinnvoll?

Ich herzlich einverstanden, dass in diesen seltenen Fällen, in denen es legitim ist, sollten Sie auch einen Kommentar zu erklären, warum die Ausnahme ist, irrelevant oder unmöglich. Aber dann würd ich sagen, dass, Wann immer Sie code schreiben, der ist möglicherweise kryptisch, sollten Sie auch einen erklärenden Kommentar.

Randnotiz: Warum ist es, dass Programmierer routinemäßig gehören Kommentare wie "x=x+1; //add 1 to x", wie duh, ich hätte nie digured, dass ohne den Kommentar, aber dann wirft wirklich kryptischen code ohne Erklärung?

Nachtrag vier Jahre nach meinem ursprünglichen post

Natürlich der WAHRE Grund, warum selbst gute Programmierer manchmal schlucken Ausnahmen ist: "ich versuche, die grundlegende Logik funktioniert, ich bin mir nicht sicher, was zu tun ist, wenn diese Ausnahme passiert, ich don' T wollen, um Durcheinander mit es jetzt, ich habe viel zu viel ärger mit der normalen Logik fließen, aber ich komme später zurück." Und dann vergessen Sie wieder an zu gehen.

BTW ein schlechter Grund, ich habe gehört von einigen Leuten, die ich generell denke, dass sind ziemlich gute Programmierer ist: "ich will nicht zur Anzeige eine kryptische Fehlermeldung an den Benutzer. Das würde nur verwirren Sie. Besser, schweigend schlucken Sie die Fehler." Das ist ein schlechter Grund, denn a) könnte Man noch etwas schreiben einer log-Datei. Und (b) Ist eine kryptische Fehlermeldung wirklich Schlimmeres, als dass der Benutzer den Eindruck, dass der Vorgang erfolgreich war, wenn nicht? Nun wird der Kunde denkt, dass Ihre Bestellung wird bearbeitet, wenn es wirklich nicht oder Sie denken, dass der Krankenwagen, der ausgelöst wird, um zu helfen, Ihr Kind zu Schreien in Agonie, aber wirklich die Nachricht ging nie durch, etc. Selbst in den trivialsten Fällen, eine fade, post auf einem forum nicht passieren, oder so, ich würde mit lieber eine kryptische Nachricht, die zumindest gibt mir die Idee, dass etwas schief gegangen ist und wenn ich sorgen ich sollte versuchen Sie es erneut oder rufen Sie jemand, dann sagen Sie einfach "update complete", wenn es wirklich nicht.

Weil etwas schon fertig zu sein für eine Präsentation, die der Chef spontan nicht morgen, und nichts ist schlimmer, als das Programm zum Absturz zu bringen oder zu zeigen, eine böse Fehlermeldung, wenn etwas gerade nicht funktioniert kann er immer "Drum herum reden", dass.

Nach der Präsentation wird man keine Verbesserung dieser "quick Fix" - Teile natürlich. 😉

Ich glaube, dass es ist, weil der Java ' s checked exceptions. Ich persönlich hasse Sie deswegen, weil Menschen dazu neigen zu denken, Sie brauchen exception-handling-code überall. IMO in 99% der code sollten Sie nur werfen Sie Ihre Ausnahme in den stack und nicht handling es. Ich würde mich freuen, wenn die Standard-Signatur für alle neuen Methode erstellt hatte 'throws Exception' in ihm, so dass ich nicht zu tun haben mit Ausnahmen, es sei denn, ich will.

IMO brauchen Sie nur die Ausnahme-Behandlung an zwei Orten:
1. Für die Ressourcen-Aufräumarbeiten wie das schließen einer Eingabe-stream, der Datenbank-Verbindung oder löschen einer Datei.
2. Ganz oben auf dem Stapel, wo Sie fangen die exception und entweder melden Sie es oder zeigen Sie es an den Benutzer.

Gibt es Orte, wo Sie wirklich nicht brauchen, etwas zu tun, in der catch-wie der Umgang mit der InterruptedException von Thread.sleep() und dort sollten Sie zumindest einen Kommentar deutlich zu machen, dass Sie wirklich nicht wollen, etwas zu passieren.

Ich habe dies getan, wenn es etwas ist, einige Stück code, wo unabhängig davon, dass es andernfalls möchte ich das Programm, um fortzufahren. Zum Beispiel habe ich geöffnet habe, eine optionale log-Datei, und unabhängig davon, warum es nicht funktionierte möchte ich auch weiterhin die Ausführung des Programms.

Sogar so, obwohl es nicht guter code, wie Sie bekommen können Ausnahmen wie die out-of-memory-Ausnahmen, die zu ignorieren macht überhaupt keinen Sinn, selbst wenn ich es getan habe, es ist noch nicht die beste Idee und würde ich nicht zugeben, es zu tun in der öffentlichkeit. (Hoppla...)

Habe ich es geschafft auf Programme, die ausgeführt werden sollen, sobald konvertieren einige Daten oder so etwas, nur ein Herunterfahren des compiler-up. Das ist eine ganz andere situation, auf jede form der Produktion code obwohl.

Grundsätzlich gibt es keinen guten Grund für diese andere als lazyness.

Mache ich es, wenn eine Ausnahme nicht behandelt werden wirksam, sollte aber keine Auswirkungen auf den normalen Betrieb der Anwendung, und/oder es könnte ein vorübergehender Zustand, das ist bekannt, aber hat insgesamt geringe Auswirkungen.

Ein einfaches Beispiel ist die Protokollierung. Sie nicht brauchen, die app zu sprengen, nur weil einige logging-Informationen werden nicht gespeichert, um Ihre backing-store.

Ein weiteres Beispiel könnte sein, wo Sie haben, alternative Mittel der Behandlung der Situationen, wie diese:

private Boolean SomeMethod() {
   Boolean isSuccessful = false;
   try {
      //call API function that throws one of several exceptions on failure.
      isSuccessful = true;
   } catch(Exception) { }

   return isSuccessful;
}

Im obigen Beispiel, Sie möglicherweise nicht haben eine fall-back-position, aber Sie nicht wollen, es zu filtern. Das ist ok für KURZE Methoden, bei denen der Rückgabewert ist nur ein status erfolgreich als der Letzte Schritt in den try-block.

Leider gibt es viele Anrufe, die werfen Ausnahmen, anstatt einfach einen Fehler-code oder false, Zustand des Ergebnisses. Ich habe auch gesehen, die fordert, dass werfen mehr Ausnahmen als das, was Ihre Dokumentation schlägt, das ist einer der Gründe, warum ich werde einen fangen alle um Sie herum.

Wie etwa bei der Durchführung einer progress-Steuerung-update? Ich habe aktualisiert die Variablen, die von einer control drawing routine, also das nächste mal die Kontrolle gezogen wird, wird es zeigen den ordnungsgemäßen Zustand. Ich dann ausführen:

 Versuchen 
MyControl.BeginInvoke(MyControlUpdateDelegate); 
Catch Ex as Exception 
End Try 

Wenn die Steuerung noch immer vorhanden ist, aktualisiert. Wenn es mal entsorgt, ich nicht egal, ob er aktualisiert wird oder nicht. Wenn die Steuerung nicht entsorgt, kann aber nicht aktualisiert werden, für einige andere Grund, ich immer noch nicht wirklich darum kümmern, ob er aktualisiert wird oder nicht, denn ich bin nicht geneigt, um in der Lage zu tun, etwas vernünftiges über es trotzdem.

Beachten Sie, dass ich hinzufügen könnte, "Wenn Nicht MyControl.IsDisposed Dann...", aber das würde nur hinzufügen, dass die Arbeit zu den Allgemeinen Fall, und würde nicht verhindern, dass die Ausnahme, die Auftritt, wenn das Steuerelement wird entsorgt, während der BeginInvoke.

verwenden wir die Ausnahmen für die Laufzeit der Irrt. da der Benutzer und manchmal Anforderungen und solche Dinge, die Auftritt, wenn es ein problem gibt. und wenn wir zeigen wollen, die Fehler an den Benutzer, die wir aufwerfen könnten Ausnahmen.
zB:-

1. wenn die software ausgeführt wird, gibt es möglicherweise eine Anforderung irren und es kann gelöst werden, indem die
   das Programm selbst. also, in solchen Fällen, der Programmierer entscheidet selbst, try-Anweisungen, und es kann eine Hardwarekomponente, die nicht gelöst werden kann, indem die software in solchen Fällen ist der Programmierer wählt den Pfad von dem auslösen einer Ausnahme zur Warnung des Benutzers vor.

und es gibt viele Fälle, dass wir den Pfad wählen, eine Ausnahme auszulösen oder die Handhabung von Ausnahmen die situation egal.

Vielleicht, weil es sich nicht durchsetzen, sondern muss in der Lage sein sowieso. Ich kann nicht aus irgendeinem Grund denken, warum zu vermeiden, irgendeine Art von handler, obwohl.

Meist, weil Sie zu müde sind. Aus demselben Grund wie Sie das vergessen-Dokumentation, wenn Sie einige Zeit.