Direkt zum Hauptbereich

Vergebung bitte!


"Es ist leichter um Vergebung zu bitten, als um Erlaubnis zu fragen"(EAFP)

Ich verweise auf dieses bei Python etablierte Prinzip, um damit meiner Liste von If-Alternativen eine weitere Möglichkeit hinzuzufügen.

Statt also vor dem Aufruf einer Funktion abzufragen, ob deren Aufruf vielleicht eine Ausnahme auslöst (Erlaubnis), ruft man statt dessen einfach die Funktion auf und reagiert im Nachgang auf eventuelle Ausnahmen (Vergebung).

Dieses Vorgehen ist für Entwickler, die aus anderen Sprachen wie Java oder C# kommen zuerst befremdlich, da dort Exceptions als teuer gelten.

Wenn man sich jedoch daran gewöhnt hat, stellt sich EAFP als viel sauberer da. Zum einen findet die Überprüfung der möglichen Fehlerursachen in genau der Funktion statt, die am besten weiß, welche Probleme ihre Operationen bewirken können. Das trägt dem Single Responsibility Prinzip Rechnung. Warum sollte jeder Aufrufer immer wieder den selben Code schreiben müssen, der eigentlich gar nicht in seiner Verantwortung liegt?

Aus dem selben Grund ist EAFP auch sicherer, da ich so keine Bedingung bei der Prüfung vergessen kann.

Ich will eine Datei öffnen und denke vielleicht noch daran, dass diese Datei ja nicht existieren könnte. Also frage ich vor dem Öffnen noch die Existenz der Datei ab. Ich vergesse aber, dass der Zugriff auch wegen fehlenden Rechten scheitern kann. BAM! Nicht behandelte Ausnahme.

Da lasse ich doch lieber gleich die Open-Funktion alles selber testen und behandle jede Ausnahme fachmännisch.

Und was hat Pippi Langstrumpf damit zu tun? Na hat die jemals um Erlaubnis gebeten? (Naja, um Vergebung allerdings auch nicht...)

 

Kommentare

  1. Auch nach nun fast 5 Jahren mit Python ist dies für mich immer noch befremdlich. Vermutlich stört mein Auge die try-catch Blöcke. An vielen Stellen fände ich es ausreichend, wenn zum Beispiel ein None Wert zurückgeliefert würde, statt gleich eine Exception zu werfen. Vermutlich liegt das auch daran, dass an einigen Stellen im Projekt schlecht geschriebener Code existiert, der jedesmal eine Exception wirft, wenn es für eine Suchanfrage kein Ergebnis gibt. Für mich ist eine leere Ergebnismenge aber auch ein valides Ergebnis und sollte nicht zu einer Exception führen.

    AntwortenLöschen
  2. Auch hier gilt, wie überall: Das richtige Werkzeug für die passende Aufgabe.

    Eine Prozedur (um mal den Pascal-Jargon zu nutzen), die nichts zurückgeben soll, kann (und sollte) Fehler nur über Exceptions kommunizieren.

    Eine Funktion sollte, so mein Philosophie, so implementiert sein, dass sie nur gültige Werte zurückliefert. Es muss möglich sein, mit dem Rückgabewert weiterzuarbeiten, ohne Überprüfungen auf Gültigkeit vornehmen zu müssen.

    Also eine Funktion, die, wie oben von dir beschrieben, eine Liste von Elementen zurückliefert, kann ohne Probleme auch eine leere Liste zurück liefern. Die kann ich ohne weiteren Check in eine foreach-Schleife stecken, ohne dass es zu Problemen kommt.

    Eine Exception wäre nur dann zurechtfertigen, wenn aus irgendeinem Grund kein gültiger Wert zurückgeliefert werden kann. Z.B. ein File-Handle für eine nicht existierende zu lesende Datei.

    Aber auch hier könnte das Pattern "Null-Objekt" Anwendung finden.

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Spezifisch unspezifisch

Ich habe mir vor einiger Zeit einmal eine Studie zur selbsternannten "geschlechtergerechten Sprache" angesehen, die beweisen soll, dass sich nur durch diese Sprachvariante Frauen und Mädchen angesprochen fühlen. Diese Studie muss eine Leuchtturmstudie sein, denn sie wird in den Medien ständig angeführt. Z.B. bei Quarks , Verdi oder RND . Bei letzterem steht dazu: In einer Studie aus dem Jahr 2015 wurde ein Experiment mit fast 600 Grundschulkindern durchgeführt. Dabei wurden ihnen Berufe entweder in der männlichen und weiblichen Form oder im generischen Maskulinum vorgelegt. Mädchen trauten sich eher traditionell männliche Berufe zu, wenn die Berufsbezeichnung gegendert wurde. Es handelt sich hierbei um die Studie "Yes I Can! – Effects of Gender Fair Job Descriptions on Children’s Perceptions of Job Status, Job Difficulty, and Vocational Self-Efficacy" . Bevor ich mir diese Studie anschaute, hatte ich schon den Gedanken: Eigentlich widerlegt diese Studie ja die gesa

Männer sind nicht wertvoll genug, um nicht im Kampf eingesetzt zu werden

Arne Hoffmann hat einen Artikel von Bettina Arndt in Teilen übersetzt . Ich frage mich nun, ob diese unterschiedliche Wertung von Leben, die Arndt beschreibt, zu tief, vielleicht sogar genetisch, in uns verankert ist; und wir deswegen niemals wirkliche Gleichberechtigung erreichen werden/können. Sind wir vielleicht nur in der Lage, weil es unserer kulturellen/biologischen Programmierung entspricht, Empathie für Frauen und Mädchen zu empfinden, nicht jedoch für Männer und Jungen? Ist deswegen der Feminismus nur eine andere Variante der Jahrtausende alten Ritterlichkeit und des Gentlemantums ("Mädchen schlägt man nicht." - "Frauen und Kinder zuerst" und damit aber implizit: "Jungen darf man schlagen", "Männer zuletzt.")? Müssen wir also einfach akzeptieren, dass unsere Gemeinschaft nur weibliche Menschen vor Gewalt schützen will und dass männliche Menschen sich eben verletzen, verstümmeln und töten lassen müssen?

Vorbereitungen

Wie jeder hinreichend gebildete Mensch weiß, kommt nach der Impfung die Zombieapokalypse (ein Wort mit drei aufeinanderfolgenden Vokalen. Deswegen schreibt man es oft mit Bindestrich. Aber ich gebe Euch die volle Deutschdröhnung!) Da gilt es vorbereit zu sein. Ich habe natürlich einige Zombiefilme und -comics konsumiert. Auch einschlägige Sachbücher von Max Brooks zu dem Thema habe ich studiert ( Der Zombie Survival Guide: Überleben unter Untoten , World War Z: Operation Zombie ). Vorräte sind bereits angelegt. Das Haus muss noch zombiesicher gemacht werden. Meine Frau weigert sich aber immer noch, die Fenster zu verbarrikadieren. Uneinsichtig! Nun stehe ich hier und überlege, welches Werkzeug wohl die beste Waffe wäre, um Zombies abzuwehren.    Wachsam bleiben!