"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...)
Und was hat Pippi Langstrumpf damit zu tun? Na hat die jemals um Erlaubnis gebeten? (Naja, um Vergebung allerdings auch nicht...)
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öschenAuch hier gilt, wie überall: Das richtige Werkzeug für die passende Aufgabe.
AntwortenLöschenEine 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.