Wenn Ausnahmen erforderlich sind

Vorwort


Das Thema Ausnahmen (Vor- und Nachteile) ist nicht neu und wurde bereits mehrmals erörtert. Trotzdem hoffe ich, dass jeder, der diesen Artikel liest, etwas Neues und Nützliches für sich selbst lernt.

Der Grund für die Veröffentlichung dieser Veröffentlichung war die Abneigung zu schweigen und nur zuzusehen, wie die „Besserwisser“ das Internet füllen, die Neulingen auf unserem Gebiet beibringen, Nägel mit einem Mikroskop zu hämmern, und dabei Dutzende von Argumenten finden, um ihre Methoden zu verteidigen! Daher richtet sich diese Veröffentlichung eher an Anfänger, die das Programmieren verstehen und Fragen stellen möchten. Sie ist meine "richtige Antwort"

Was genau ist eine Ausnahme?


BildEine Ausnahme ist, dass die Wahrscheinlichkeit (Möglichkeit) davon vom System ausgeschlossen wird ... das kann in der Programmumgebung nicht passieren.

Schau in deinen Code. Können Sie zu jeder Ausnahme hinzufügen, "aber es ist unmöglich" oder "aber es ist ausgeschlossen"? Ich denke, nur wenige Menschen können ehrlich mit "Ja" antworten. Wenn Sie mit „Nein“ antworten, bedeutet dies, dass einige der Ausnahmen nicht wirklich die gleichen sind. Sie haben einfach diesen Mechanismus verwendet, weil es Ihnen bequemer erschien. Die eigentliche Zweckmäßigkeit eines solchen Ansatzes wird im Folgenden erörtert.

Wer sollte bestimmen, welche Situationen das Programm beseitigt und welche nicht?


Alle Ausnahmen können nur von der Aufgabe oder dem gesunden Menschenverstand und von nichts oder von jemand anderem diktiert werden . Eine Ausnahme wird weder durch die Art der Daten noch durch ihre Quelle bestimmt, obwohl man in „intelligenten“ Artikeln häufig hört oder liest: „Falsche Client-Eingaben können keine Ausnahme sein“ ... glauben Sie es nicht! Ich muss es einfach nicht glauben.

Bei der Aufgabe können Sie eine ganz vernünftige Ausnahme von falschen Kundeneingaben erhalten: "Speziell geschulte Manager unseres Unternehmens arbeiten mit dem System, daher ist die Eingabe falscher Daten ausgeschlossen" oder "Der Manager lädt Briefe in das System, die die Richtigkeit des Formats bereits bestanden haben, so dass das Format immer genau ist so ein ". Jetzt hat Ihnen der Kunde selbst mitgeteilt, wo Sie eine Ausnahme im für ihn geschriebenen Programm auslösen sollen (und es ist in Ordnung, dass dies Client-Eingaben sind). Wenn es sich immer noch um ein bestimmtes Produkt und nicht um eine Bibliothek handelt, muss das Programm natürlich nicht einfach fallen gelassen werden. Lassen Sie den Ausnahmebehandler auf der obersten Ebene hängen und verwandeln Sie alle nicht behandelten Ausnahmen in Fehler, speichern Sie die Daten und schließen Sie die Ausführung vorsichtig ab (oder übertragen Sie die Steuerung an das Hauptmodul, wenn der Fehler nicht darin enthalten ist).

Vergessen Sie jedoch nicht, wie üblich zwischen den Zeilen zu lesen und die Aufgabe zu klären. Wenn Sie aufgefordert werden, die Datei zu speichern, prüfen Sie, ob die Datei möglicherweise nicht gespeichert wird. Und wenn Sie sich entscheiden, keine Angabe zu machen, schließen Sie eine solche Wahrscheinlichkeit nicht aus, sondern implementieren Sie eine Reaktion auf dieses Ereignis. Ihr Code sollte zu nichts schweigen.

Entweder vorhersehen oder ausschließen.

Warum ist eine zusätzliche Ausnahme für den Code schädlich?


Mehr als einmal bin ich auf eine Situation gestoßen, in der ausnahmsweise ein negatives Ergebnis der Funktion zurückgegeben wurde, obwohl ein solches Ergebnis von der Aufgabe selbst bereitgestellt wurde. In diesem Zusammenhang hörte ich verschiedene Erklärungen:

  • Übergeben Sie das Beendigungsflag nicht in der gesamten Aufrufkette
  • Ich muss die gesammelten Daten übertragen, bevor ich eine negative Antwort erhalte
  • Eine Funktion kann aus drei Gründen ein negatives Ergebnis liefern. Es ist einfacher, diesen Grund zu vermitteln.
  • viele andere Gründe ...

Warum machst du das nicht? Ja, weil:
Bild
  • Sie können die Methoden, die bereits an anderen Stellen geschrieben wurden, nicht sicher verwenden, da sie unerwartete Ausnahmen auslösen können.

  • GOTO ist böse - weil es den Code verwirrt und die Kontrolle an einen beliebigen Punkt übergibt. Sie sollten nicht glauben, dass die Übertragung der Kontrolle durch das Überspringen einer beliebigen Anzahl von Aufrufen auf dem Stapel Ihren Code weniger verwirrt als GOTO.

  • Jemand und möglicherweise Sie selbst müssen dann etwas im geschriebenen Code korrigieren oder hinzufügen. Es ist nicht davon auszugehen, dass Sie sich nach 2 Jahren daran erinnern werden, dass dieses Modul des Systems Ausnahmen für negative Antworten verwendet. Das heißt, Sie müssen sich mit ... und nicht nur mit dem Code, sondern auch mit allen „ungewöhnlichen“ Ansätzen befassen.

Ich habe in die obige Liste keine Argumente wie "Dies ist eine Regel des guten Geschmacks" und "Lasst uns alles für den vorgesehenen Zweck verwenden" aufgenommen, sodass es bereits genug geschrieben wurde.

Fazit


Ich habe versucht, nicht auf unnötige Details einzugehen und jedem Vorschlag die größtmögliche Bedeutung zu geben. Ich hoffe, es ist mir gelungen, und wenn Sie diese Zeilen lesen, denken Sie: „Fünf Minuten und so viel Neues!“ Nun, ich hoffe es.

Am Ende möchte ich sagen, dass Sie nicht unter dem Druck von Faktoren, Terminen und "genauso einfach" ausweichen und den falschen Code schreiben sollten, sondern schnell.

Die Perfektion und Fehlertoleranz unseres Codes bestimmen unsere Professionalität.

Jetzt auch beliebt: