Scheitern vs. Erhöhung in Ruby : Sollen wir wirklich glauben, dass der style-guide?

Ruby bietet zwei Möglichkeiten, um zu bewirken, dass eine Ausnahme programmatisch: raise und fail sowohl als Kernel Methoden. Nach den Unterlagen, Sie sind absolut gleichwertig.

Aus Gewohnheit, habe ich nur raise so weit. Nun fand ich mehrere Empfehlungen (zum Beispiel hier), zu verwenden raise Ausnahmen gefangen werden, und fail für schwerwiegende Fehler, die sind nicht dazu gedacht, bearbeitet zu werden.

Aber macht es wirklich Sinn? Beim schreiben einer Klasse oder Modul, und zu einem problem führen, tief im inneren, die Ihr signal von fail Ihre Programmier-Kollegen, die überprüfung der code, vielleicht glücklich zu verstehen, Ihre Absichten, sondern die person, die mit mein code wird wahrscheinlich nicht Blick auf meinen code und hat keine Möglichkeit zu wissen, ob die Ausnahme war, verursacht durch eine raise oder durch fail. Daher mein vorsichtiger Verwendung von raise oder fail können, haben keinen Einfluss auf seine Entscheidung, ob Sie sollte oder sollte nicht umgehen.

Könnte jemand sehen, Fehler in meinen Argumenten? Oder gibt es andere Kriterien, die könnten mich benutzen wollen fail statt raise?

  • Ich denke, dass diese Frage behandelt werden könnten als off-topic, da es nicht bestehen, ein bestimmtes problem, also meiner Meinung nach ist es besser geeignet, zum Beispiel auf Programmierer
  • bei verweisen auf andere Websites, ist es oft hilfreich, zu zeigen, dass cross-posting ist verpönt
  • Tatsächlich, das problem entstand aus einem spezifischen problem (ich Schreibe eine Bibliothek und möchten eine Ausnahme auslösen, wenn ein argument an eine Methode übergeben wird out-of-range), aber ich dachte, dass die Bereitstellung dieser Informationen nicht helfen, die Frage zu beantworten. Danke aber für die Kommentare.
InformationsquelleAutor user1934428 | 2015-08-11
  1. 42

    verwenden 'erhöhen' für Ausnahmen gefangen werden, und "fail" für schwerwiegende Fehler, die sind nicht dazu gedacht, bearbeitet zu werden

    Dies ist nicht das, was die offiziellen style-guide oder dem link, den Sie sagen auf die Frage.

    Was hier gemeint ist, ist die Verwendung raise nur in rescue Blöcke. Aka verwenden fail wenn Sie etwas sagen wollen ist scheitern und verwenden raise wenn erneute auslösen eine Ausnahme.

    Als für die "ist es egal" Teil - es ist nicht einer der am meisten hardcore strikt befolgt Regeln, aber man könnte das gleiche argument für jede Konvention. Sollten Sie in dieser Reihenfolge:

    1. Ihr Projekt style guide
    2. Ihrer Firma style-guide
    3. Der Gemeinschaft style guide

    Idealerweise, die drei sollten gleich sein.

    Update: Als der diese PR (Dezember 2015), die convention ist immer raise.

    • Vielen Dank für die Klärung! Das macht es für mich klar, (obwohl ich bin immer noch etwas verwundert über die Nützlichkeit dieser Regel, da kann ich mich im Allgemeinen einfach aus dem code sehen, ob ich erneute auslösen einer exception oder nicht. So weit ich es verstehe, nichts wird gewonnen, indem zusätzlich betont diese Tatsache, indem Sie mit einem anderen Befehl.
    • es ist genau der richtige name für den richtigen Fall. Auch, stellen Sie sich vor, Sie möchten etwas mehr Verarbeitung umschließt, die die ursprüngliche Ausnahme (zum Beispiel) im Falle eines Fehlers. Daher, Sie möglicherweise erstellen Sie eine eigene private Methode für, die. Es wird nützlich sein, um zu sehen raise statt fail es als das erneute auslösen nicht vorangestellt werden rescue.
    • Guter Punkt! Zustimmen ....
    InformationsquelleAutor ndnenkov
  2. 4

    Ich hatte einmal ein Gespräch mit Jim Weirich über diese sehr Sache, ich habe da früher immer fail wenn meine Methode ist ausdrücklich versagt aus irgendeinem Grund, und raise zu re-Ausnahmen ausgelöst.

    Hier ist ein post mit einer Nachricht von Jim (fast wörtlich, was er sagte, zu mir in person:
    http://www.virtuouscode.com/2014/05/21/jim-weirich-on-exceptions/

    Hier ist der relevante text aus dem post, ein Zitat zugeschrieben, Jim:

    Hier ist meine grundsätzliche Philosophie (und andere zufällige Gedanken) über Ausnahmen.

    Wenn Sie eine Methode aufrufen, haben Sie bestimmte Erwartungen über das, was die Methode erreicht werden. Formal sind diese Erwartungen sind als post-Bedingungen. Eine Methode soll eine exception werfen, wenn es nicht zu erfüllen, seinen nachbedingungen.

    Effektiv diese Strategie verwenden, es bedeutet, Sie müssen eine kleine Verständnis von Design by Contract und die Bedeutung von pre - und post-Bedingungen. Ich denke, das ist eine gute Sache zu wissen, sowieso.

    Hier einige konkrete Beispiele. Die Schienen-Modell save Methode:

    model.save!
-- post-condition: The model object is saved.

    Wenn das Modell nicht gespeichert, aus irgendeinem Grund, wird eine Ausnahme ausgelöst werden muss, weil die post-Bedingung ist nicht erfüllt.

    model.save
-- post-condition: (the model is saved && result == true) ||
                   (the model is not saved && result == false)

    Wenn save eigentlich nicht sparen, dann ist das zurückgegebene Ergebnis wird false , aber die post-Bedingung ist immer noch erfüllt, also keine Ausnahme.

    Ich finde es interessant, dass die save! Methode hat eine weitaus einfachere post-Zustand.

    Auf das Thema der Rettung von Ausnahmen, ich denke, eine Bewerbung sollte strategische Punkte, wo Ausnahmen sind gerettet. Es gibt wenig Notwendigkeit für die Rettung/rethrows für die meisten Teil. Die einzige Zeit, die Sie möchten, um zu retten und rethrow ist, wenn Sie einen job haben, auf halbem Weg getan, und Sie rückgängig machen wollen so etwas vermeiden, die einen teilweise kompletten Zustand. Ihre strategische rescue Punkte sollten sorgfältig ausgewählt werden, so dass das Programm weiter mit den anderen arbeiten, auch wenn der aktuelle Vorgang ist fehlgeschlagen. Transaction processing-Programme sollten einfach bewegen auf die nächste Transaktion. Eine Rails-app sollte sich erholen und bereit sein, zu handhaben die nächste http-Anforderung.

    Meisten exception-Handler sollte generisch sein. Da Ausnahmen deuten auf einen Fehler von einem Typ, dann wird der handler muss nur eine Entscheidung treffen, was zu tun ist, im Falle des Scheiterns. Detaillierte recovery-Vorgänge für sehr spezifische Ausnahmen sind in der Regel abgeraten, es sei denn der handler ist sehr nah (call-graph-Weise) auf den Punkt, die Ausnahme.

    Ausnahmen sollten nicht verwendet werden, die für die Ablaufsteuerung, verwenden Sie throw/catch für, die. Diese behält sich vor, Ausnahmen für echte Fehlerbedingungen.

    (Nebenbei, weil ich exceptions verwenden, um anzugeben, Ausfälle, ich verwende fast immer die fail - Schlüsselwort anstelle der raise Schlüsselwort in Ruby. Fail und raise Synonyme sind, so gibt es keinen Unterschied außer, dass fail mehr klar communcates, dass die Methode fehlgeschlagen ist. Die einzige Zeit, die ich verwenden raise ist, wenn ich bin, fangen eine Ausnahme und re-raisen, weil ich hier bin nicht Versagen, sondern explizit und gezielt auslösen einer exception. Dies ist eine stilistische Frage, die ich Folgen, aber ich bezweifle, dass viele andere Menschen tun).

    Dort haben Sie es, eine eher weitläufige memory dump auf meine Gedanken auf Ausnahmen.

    Ich weiß, dass es viele Stil-Führer, die nicht Stimmen (die style guide verwendet RoboCop, zum Beispiel). I don ' T care. Jim hat mich überzeugt.

    InformationsquelleAutor Karl Wilbur
Schreibe einen Kommentar