Sind die Prinzipien der ausfallsicheren und ausfallsicheren Ausnahmebehandlung unvereinbar?

Question

Ich würde gerne besser verstehen, was ausfallsicher und ausfallfrei ist.

Auf den ersten Blick sieht es so aus, als ob Fail-Fast bedeutet, dass wir das System eindeutig zum Scheitern bringen wollen, wenn etwas Unerwartetes passiert. Ich meine zum Beispiel, wenn eine Fabrik keine Instanz eines Objekts erstellen kann, wollen wir wirklich nicht, dass die Fabrik null oder ein leeres Objekt oder ein teilweise initialisiertes Objekt zurückgibt, das zufällig von der Anwendung korrekt verwendet werden könnte -> meistens hätten wir ein unerwartetes Verhalten oder eine unerwartete Ausnahme, die auf einer anderen Ebene ausgelöst würde, die es uns nicht erlauben würde, zu wissen, dass das eigentliche Problem in der Fabrik liegt. Was bedeutet dieses Prinzip?

Das Prinzip der Ausfallsicherheit ist für mich ziemlich schwer zu verstehen. Das häufigste Beispiel in Java sind die Sammlungen, ihre Iteratoren und der gleichzeitige Zugriff. Man sagt, dass eine Sammlung/ein Iterator, der es erlaubt, eine Liste zu ändern, während man über sie iteriert, ausfallsicher ist. Normalerweise wird dies durch abschließende Iteration über eine Kopie der ursprünglichen Liste erreicht. Aber in diesem Beispiel verstehe ich nicht wirklich, wo das System versagt... und daher, obwohl es ausfallsicher ist... Wo ist der Fehler? Wir iterieren einfach über eine Kopie oder nicht, je nach unseren Bedürfnissen... Ich sehe keine Übereinstimmung mit der Wiki-Definition von Fail-Safe...

So in solchen Artikeln wie: http://www.certpal.com/blogs/2009/09/iterators-fail-fast-vs-fail-safe/ Das Gegenteil von ausfallsicher ist ausfallsicher... ich verstehe nur nicht, warum wir diese Iteration über eine Kopie ausfallsicher nennen...

Ein weiteres Beispiel habe ich hier gefunden: http://tutorials.jenkov.com/java-exception-handling/fail-safe-exception-handling.html Es scheint viel mehr mit der ursprünglichen Definition des Fail-Safe-Prinzips zu tun zu haben. Unter Ausfallsicherheit verstehe ich, dass wir bei einem Systemausfall sicherstellen müssen, dass der Fehlerbehandler nicht ausfällt oder, falls doch, dass das eigentliche Problem nicht durch den Ausfall des Handlers verdeckt wird. In diesem Beispiel liegt der Handler in der Nähe des ursprünglichen Fehlercodes, aber das ist nicht immer der Fall. Ausfallsicherheit bedeutet für mich eher, dass wir die Fehler, die in den Fehlerbehandlungsroutinen auftreten können, korrekt behandeln oder so ähnlich...

Daher scheinen mir diese beiden Grundsätze nicht unvereinbar zu sein. Was meinen Sie dazu? Kann ein System nicht schnell und sicher ausfallen???

Answer 1

Es ist besser, Fehler von vornherein zu vermeiden (Fail Safe), aber wenn dies nicht möglich ist, ist es am besten, schnell zu versagen (so schnell wie möglich zu versagen).

Die beiden sind keine Gegensätze, sondern ergänzen sich.

Wie Sie sagen - ich möchte, dass mein Code so sicher wie möglich ist, aber wo das nicht der Fall ist, möchte ich, dass er schnell versagt.

Answer 2

ausfallsicher bedeutet nicht, dass etwas nicht versagen wird - es bedeutet, dass, wenn es versagt, es auf sichere Weise versagt. Etwas, das nicht versagen kann, ist ausfallsicher -- wenn das überhaupt möglich ist.

Ein ausfallsicherer Aufzug bleibt bei einem Kabelbruch an seinem jetzigen Standort stecken. Die Fahrgäste sitzen zwar fest, sind aber glücklicherweise nicht tot.

Nehmen wir das Beispiel eines Iterators. Die Theorie besagt, dass es besser ist, dem Client-Code sofort zu signalisieren, dass etwas nicht in Ordnung ist, als blind eine gültig aussehende Antwort zurückzugeben, die im weiteren Verlauf ernstere Probleme verursachen kann. Wenn der Client-Code sicherheitsbewusst ist, hat er die Möglichkeit, sofort einzugreifen und Abhilfe zu schaffen. So auch in diesem Fall, ausfallsicher y schnell scheitern sind miteinander vereinbar, wobei letzteres eine Strategie ist, um ersteres zu erreichen.

Stellen Sie sich andererseits einen Webbrowser in den Händen einer Person vor, die sich mit Computern nicht auskennt. Er versucht zu sehen, wann sein Film beginnt. Nehmen wir an, dass (Gott bewahre) das HTML auf der Seite nicht wohlgeformt ist. Wenn der Renderer schnell versagen würde, könnte er beschließen, die Informationen, die der Benutzer sehen will, nicht zu rendern, weil eine vorhergehende <HR> Tag ist buchstabiert <H> . In diesem Fall ist es besser, einfach weiterzumachen und die Seite so gut wie möglich zu rendern. Der Fehler könnte unbedeutend sein und nie bemerkt werden, oder er könnte viel, viel später bemerkt werden, wenn jemand endlich bemerkt, dass die Seite nicht ganz richtig aussieht. Hier ist also ein Beispiel, bei dem schnell scheitern ist keine gute Strategie für ausfallsicher .

Wenn es sich bei der Webseite um meine Online-Banking-Anwendung handeln würde, würde ich sicher wollen, dass sie spektakulär in die Luft fliegt (natürlich mit einem Rollback), wenn auch nur der kleinste Fehler auftritt. Also dann schnell scheitern wieder die Strategie der Wahl für ausfallsicher .

Mein Standpunkt ist, dass ausfallsicher ein eigenständiger Begriff ist, und dass schnell scheitern kann, muss aber nicht eine bestimmte Technik sein, die zur Ausfallsicherheit beiträgt.