Ausnahmen für den Kontrollfluss

Question

Es gibt ein interessanter Beitrag hier in Bezug auf den anwendungsübergreifenden Kontrollfluss.

Nun, vor kurzem bin ich auf ein interessantes Problem gestoßen. Die Generierung des n-ten Wertes in einer potenziell (praktisch) endlosen rekursiven Folge. Dieser spezielle Algorithmus wird an dem Punkt, an dem er erfolgreich ist, mindestens 10-15 Stapelverweise tief sein. Mein erster Gedanke war, eine SuccessException auszulösen, die etwa so aussieht (C#):

class SuccessException : Exception
{
    public string Value
    { get; set; }

    public SuccessException(string value)
        : base()
    {
        Value = value;
    }
}

Dann machen Sie etwas Ähnliches:

try
{
    Walk_r(tree);
}
catch (SuccessException ex)
{
    result = ex.Value;
}

Dann wanderten meine Gedanken wieder hierher, wo ich immer wieder gehört habe, dass man niemals Ausnahmen für die Flusskontrolle verwenden soll. Gibt es jemals eine Ausrede? Und wie würden Sie so etwas strukturieren, wenn Sie es einführen würden?

Answer 1

In diesem Fall würde ich Ihre Walk_r-Methode betrachten, sollten Sie etwas, das einen Wert zurückgibt, werfen eine Ausnahme, um Erfolg anzuzeigen, ist NICHT eine gängige Praxis, und mindestens wird SEHR verwirrend für jeden, der den Code sieht. Ganz zu schweigen von dem Overhead, der mit Ausnahmen verbunden ist.

Answer 2

Walk_r sollte einfach den Wert zurückgeben, wenn er getroffen wird. Das ist ein ziemlich normales Rekursionsbeispiel. Das einzige potenzielle Problem, das ich sehe, ist, dass Sie sagten, dass es potenziell endlos ist, was im walk_r-Code kompensiert werden muss, indem die Rekursionstiefe gezählt und bei einem Maximalwert gestoppt wird.

Die Ausnahme macht die Kodierung sehr seltsam, da der Methodenaufruf nun eine Ausnahme auslöst, um den Wert zurückzugeben, anstatt einfach "normal" zurückzukehren.

try
{
    Walk_r(tree);
}
catch (SuccessException ex)
{
    result = ex.Value;
}

wird

result = Walk_r(tree);

Answer 3

Ich spiele hier des Teufels Advokat und sage, dass man sich an die Ausnahme halten sollte, wenn man Erfolg haben will. Es könnte teuer sein, zu werfen / fangen, aber das kann unbedeutend sein im Vergleich zu den Kosten der Suche selbst und möglicherweise weniger verwirrend als ein früher Ausstieg aus der Methode.

Answer 4

Es ist keine gute Idee, Ausnahmen als Teil eines Algorithmus zu werfen, insbesondere in .net. In einigen Sprachen/Plattformen sind Ausnahmen ziemlich effizient, wenn sie ausgelöst werden, und das sind sie in der Regel auch, zum Beispiel wenn eine Iterable erschöpft wird.

Answer 5

Warum wird nicht einfach der resultierende Wert zurückgegeben? Wenn er überhaupt etwas zurückgibt, ist er erfolgreich. Wenn sie keinen Wert zurückgibt, bedeutet das, dass die Schleife fehlgeschlagen ist.

Wenn Sie nach einem Fehler zurückkehren müssen, empfehle ich Ihnen, eine Ausnahme zu machen.