Ich habe gelesen, wie der Fail-Fast-Programmierstil in Sprachen wie Erlang mit viel kürzeren Programmen endet als der defensive Stil in den meisten anderen Sprachen. Ist das für alle Arten von Programmen richtig und was ist der Grund dafür?Warum sind schnelle Style-Programme kürzer als defensive Style-Programme?
Fail-Fast-Programme sind nicht unbedingt kürzer als defensive Stil-Programme: Es hängt von der Implementierung und den Maßnahmen ab, die benötigt werden, um Ihren defensiven Code sicher zu machen.
Im Fall von Erlang sind die Fail-Fast-Programme in der Regel wegen des deklarativen Stils kürzer und wie die VM sicherstellt, dass Fehlerfälle für Sie generiert werden. Als Beispiel in der Funktion:
day(1) -> sunday;
day(2) -> monday;
day(3) -> tuesday;
day(4) -> wednesday;
day(5) -> thursday;
day(6) -> friday;
day(7) -> saturday;
Jedem an die Funktion übergeben unerwarteten Wert führt zu einem Fehler führen, die von einem anderen Prozess abgefangen und behandelt werden kann (dh .: ein Supervisor). Solche Fehler gefährden auch niemals das System als Ganzes und erfordern keinen Code, der der Funktion selbst hinzugefügt wird - alles geschieht außerhalb des normalen Ausführungspfades durch vorher festgelegte Verhaltensweisen.
In einer dynamischen Sprache, in der Fail-Fast nicht die Norm ist, müssten Sie die Grenzen manuell überprüfen und selbst eine Ausnahme auslösen. Dann müssen Sie die Exception lokal abfangen (Top-Level-Versuch ... Fänge eingeschlossen), wenn Sie nicht möchten, dass das ganze System ausfällt. Der Fehlerbehandlungscode muss normalerweise über den normalen Ausführungspfad eingefügt werden.
In einer statischen Sprache, in der Fail-Fast nicht die Norm ist, hängt die Länge Ihres Codes stark vom Typensystem ab, das Sie haben. Wenn es die Sprache erlaubt, Typen zu definieren, bei denen die Edge Cases vom Compiler für Sie überprüft werden, müssen Sie dies normalerweise außerhalb von nichtdeterministischen Ereignissen (Dateien funktionieren nicht, unerwartete Benutzereingaben usw.) innerhalb des Codes behandeln Sprachen mit solchen Typsystemen werden viele Fehler vor der Laufzeit abgefangen und Sie haben nicht so viele defensive Fälle.
Wenn die Fehlerbehandlung nicht vermieden werden kann, Sprache unterstützt ausfall schnell Idiome (wie Erlang) wird wohl klaren Code als Sprachen ermöglichen, die dies nicht tun (statisch oder nicht), vor allem, weil der Code für Sonderfälle isn‘ t mit dem Code für den idealen Ausführungspfad gemischt.
Der Fail-Fast-Programmierstil konzentriert sich auf bessere Code-Lesbarkeit und Debugging. Die Benutzererfahrung ist ein sekundäres Ziel: Ein Benutzer kann merkwürdige Fehlermeldungen oder Programmfehler erfahren, aber die größere Qualität des Codes ermöglicht es Programmierern, den Fehler leicht zu finden und das Problem zu beheben.
Die defensive Stilprogrammierung konzentriert sich stattdessen auf Validierungseingabe vom Benutzer und von anderen Teilen des Codes. Der Code ist ausführlicher, da der Programmierer die Eingabe sorgfältig überprüfen und im Fehlerfall fehlerfrei ablaufen muss. Dies führt zu mehr Code (aus der Sicht des Programmierers) und zu einer robusteren Anwendung (aus der Sicht des Anwenders).
Nicht korrekt. Sie verwirren den Fail-Fast-Stil mit dem fehlerfreien Bearbeitungsstil.Fail-Fast-Stil ermöglicht es Ihrem Programm immer noch, Fehler zu erkennen und sich von ihnen zu erholen, ohne den Benutzer zu stören. – Deestan
Offensichtlich profitiert der Benutzer auch die Vorteile von weniger fehlerhafter Software mit dem Failfast-Stil. Ich würde eher sagen Failfast ist über Klarheit in was ist richtige Eingabe und was falsche Eingabe ist, und dies tatsächlich durchzusetzen. Clarity liefert immer bessere Programmierung. Eingabefehler sollten als solche markiert werden (statt die App in undefiniertes Land zu lassen), aber das verhindert nicht, dass die App diesen Fehler elegant und intuitiv behandelt. Ich denke, Sie stellen eine falsche Dichotomie auf. – harms
Falsche Antwort. Im Kontext von Erlang, für den die Frage gestellt wurde, ist der robustere Ansatz, defensive Programmierung zu vermeiden und den schuldigen Prozess einfach "abstürzen zu lassen". Ein anderer Prozess führt die geeigneten Aktionen zur Wiederherstellung aus. In Java, dem Sie Erfahrung zu haben scheinen, haben Sie keine andere Wahl, als defensiv zu sein, weil es eine imperative Sprache mit einem Shared-State-Concurrency-Modell ist. Da Erlang eine funktionale Sprache mit Nebenläufigkeit bei der Nachrichtenübergabe ist und weil es Mechanismen gibt, um Fehler zwischen Prozessen zu kommunizieren, ist dies vollkommen in Ordnung und vorzuziehen gegenüber Fail-Fast. – dsmith
Siehe Abschnitte 4.3 und 4.4 von Joe Armstrongs thesis.
Link ist kaputt, aber hier ist einer, der funktioniert: http://erlang.org/download/armstrong_thesis_2003.pdf –
Abschnitt 4.5 ist meiner Meinung nach auch relevant. –
Ich werde mit der Tradition brechen und fragen, warum das Gemeinschaftswiki gemacht wurde. :) –
Soll ich es ändern, um kein Community-Wiki zu sein? Ich bin mir nie sicher, welches Ding ein Community-Wiki ist und welches nicht. – Zubair
Große Sache über Community-Wiki ist, dass Leute jede Antwort bearbeiten können, um es zu beheben, und es gibt keine Upvote-Punkte für den Benutzer, der eine Antwort gesendet hat, während normale Modus Punkte gibt und nur Benutzer mit einer minimalen Anzahl von Punkten Antworten bearbeiten können. –