Angenommen, ich habe diesen Pseudocode:

bool conditionA = executeStepA();
if (conditionA){
    bool conditionB = executeStepB();
    if (conditionB){
        bool conditionC = executeStepC();
        if (conditionC){
            ...
        }
    }
}

executeThisFunctionInAnyCase();

Funktionen executeStepXsollten genau dann ausgeführt werden, wenn die vorherigen erfolgreich sind. In jedem Fall sollte die executeThisFunctionInAnyCaseFunktion am Ende aufgerufen werden. Ich bin ein Neuling in der Programmierung, also entschuldige die sehr grundlegende Frage: Gibt es eine Möglichkeit (zum Beispiel in C / C ++) zu vermeiden, dass diese lange ifKette diese Art von "Codepyramide" auf Kosten der Lesbarkeit des Codes erzeugt? ?

Ich weiß, wenn wir den executeThisFunctionInAnyCaseFunktionsaufruf überspringen könnten , könnte der Code wie folgt vereinfacht werden:

bool conditionA = executeStepA();
if (!conditionA) return;
bool conditionB = executeStepB();
if (!conditionB) return;
bool conditionC = executeStepC();
if (!conditionC) return;

Die Einschränkung ist jedoch der executeThisFunctionInAnyCaseFunktionsaufruf. Könnte die breakAussage auf irgendeine Weise verwendet werden?

Sie können ein &&(logisches UND) verwenden:

if (executeStepA() && executeStepB() && executeStepC()){
    ...
}
executeThisFunctionInAnyCase();

Dies wird Ihre beiden Anforderungen erfüllen:

• executeStep<X>()sollte nur ausgewertet werden, wenn die vorherige erfolgreich war (dies wird als Kurzschlussauswertung bezeichnet )
• executeThisFunctionInAnyCase() wird in jedem Fall ausgeführt

Verwenden Sie einfach eine zusätzliche Funktion, damit Ihre zweite Version funktioniert:

void foo()
{
  bool conditionA = executeStepA();
  if (!conditionA) return;

  bool conditionB = executeStepB();
  if (!conditionB) return;

  bool conditionC = executeStepC();
  if (!conditionC) return;
}

void bar()
{
  foo();
  executeThisFunctionInAnyCase();
}

Wenn Sie entweder tief verschachtelte ifs (Ihre erste Variante) oder den Wunsch verwenden, aus einem "Teil einer Funktion" auszubrechen, benötigen Sie normalerweise eine zusätzliche Funktion.

gotoIn diesem Fall verwenden C-Programmierer der alten Schule . Es ist die einzige Verwendung goto, die vom Linux-Styleguide tatsächlich empfohlen wird. Sie wird als zentraler Funktions-Exit bezeichnet:

int foo() {
    int result = /*some error code*/;
    if(!executeStepA()) goto cleanup;
    if(!executeStepB()) goto cleanup;
    if(!executeStepC()) goto cleanup;

    result = 0;
cleanup:
    executeThisFunctionInAnyCase();
    return result;
}

Einige Leute arbeiten daran, gotoindem sie den Körper in eine Schleife wickeln und daraus abbrechen, aber effektiv tun beide Ansätze dasselbe. Der gotoAnsatz ist besser, wenn Sie nur dann eine andere Bereinigung benötigen, wenn dies executeStepA()erfolgreich war:

int foo() {
    int result = /*some error code*/;
    if(!executeStepA()) goto cleanupPart;
    if(!executeStepB()) goto cleanup;
    if(!executeStepC()) goto cleanup;

    result = 0;
cleanup:
    innerCleanup();
cleanupPart:
    executeThisFunctionInAnyCase();
    return result;
}

Mit dem Loop-Ansatz würden Sie in diesem Fall zwei Ebenen von Loops erhalten.

Dies ist eine häufige Situation, und es gibt viele gängige Möglichkeiten, damit umzugehen. Hier ist mein Versuch einer kanonischen Antwort. Bitte kommentieren Sie, wenn ich etwas verpasst habe und ich werde diesen Beitrag auf dem neuesten Stand halten.

Dies ist ein Pfeil

Was Sie besprechen, wird als Pfeil-Anti-Muster bezeichnet . Es wird als Pfeil bezeichnet, da die Kette verschachtelter ifs Codeblöcke bildet, die sich immer weiter nach rechts und dann wieder nach links ausdehnen und einen visuellen Pfeil bilden, der auf die rechte Seite des Code-Editor-Bereichs "zeigt".

Flache den Pfeil mit der Wache ab

Einige gebräuchliche Methoden zur Vermeidung des Pfeils werden hier erläutert . Die gängigste Methode ist die Verwendung eines Wachmusters, in dem der Code behandelt die Ausnahme erste fließt und dann übernimmt die Grundströmung, beispielsweise anstelle von

if (ok)
{
    DoSomething();
}
else
{
    _log.Error("oops");
    return;
}

... du würdest benutzen ....

if (!ok)
{
    _log.Error("oops");
    return;
} 
DoSomething(); //notice how this is already farther to the left than the example above

Wenn es eine lange Reihe von Wachen gibt, wird der Code dadurch erheblich abgeflacht, da alle Wachen ganz links angezeigt werden und Ihre Wenns nicht verschachtelt sind. Darüber hinaus koppeln Sie die logische Bedingung visuell mit dem zugehörigen Fehler, wodurch Sie viel einfacher erkennen können, was gerade passiert:

Pfeil:

ok = DoSomething1();
if (ok)
{
    ok = DoSomething2();
    if (ok)
    {
        ok = DoSomething3();
        if (!ok)
        {
            _log.Error("oops");  //Tip of the Arrow
            return;
        }
    }
    else
    {
       _log.Error("oops");
       return;
    }
}
else
{
    _log.Error("oops");
    return;
}

Bewachen:

ok = DoSomething1();
if (!ok)
{
    _log.Error("oops");
    return;
} 
ok = DoSomething2();
if (!ok)
{
    _log.Error("oops");
    return;
} 
ok = DoSomething3();
if (!ok)
{
    _log.Error("oops");
    return;
} 
ok = DoSomething4();
if (!ok)
{
    _log.Error("oops");
    return;
} 

Dies ist objektiv und quantifizierbar leichter zu lesen, weil

1. Die Zeichen {und} für einen bestimmten Logikblock liegen näher beieinander
2. Der mentale Kontext, der zum Verstehen einer bestimmten Linie benötigt wird, ist geringer
3. Die gesamte Logik, die einer if-Bedingung zugeordnet ist, befindet sich eher auf einer Seite
4. Die Notwendigkeit, dass der Codierer die Seiten- / Augenspur scrollt, wird erheblich verringert

So fügen Sie am Ende allgemeinen Code hinzu

Das Problem mit dem Schutzmuster besteht darin, dass es auf dem beruht, was als "opportunistische Rückkehr" oder "opportunistischer Ausstieg" bezeichnet wird. Mit anderen Worten, es bricht das Muster, dass jede Funktion genau einen Austrittspunkt haben sollte. Dies ist aus zwei Gründen ein Problem:

1. Es reibt einige Leute in die falsche Richtung, z. B. Leute, die gelernt haben, auf Pascal zu programmieren, haben gelernt, dass eine Funktion = ein Austrittspunkt ist.
2. Es enthält keinen Codeabschnitt, der beim Beenden ausgeführt wird, unabhängig davon , um welches Thema es sich handelt.

Im Folgenden habe ich einige Optionen bereitgestellt, um diese Einschränkung zu umgehen, indem ich entweder Sprachfunktionen verwende oder das Problem insgesamt vermeide.

Option 1. Sie können dies nicht tun: verwenden finally

Als C ++ - Entwickler können Sie dies leider nicht tun. Dies ist jedoch die Antwort Nummer eins für Sprachen, die ein Schlüsselwort finally enthalten, da dies genau das ist, wofür es ist.

try
{
    if (!ok)
    {
        _log.Error("oops");
        return;
    } 
    DoSomething(); //notice how this is already farther to the left than the example above
}
finally
{
    DoSomethingNoMatterWhat();
}

Option 2. Vermeiden Sie das Problem: Restrukturieren Sie Ihre Funktionen

Sie können das Problem vermeiden, indem Sie den Code in zwei Funktionen aufteilen. Diese Lösung hat den Vorteil, dass sie für jede Sprache funktioniert. Darüber hinaus kann sie die zyklomatische Komplexität reduzieren. Dies ist eine bewährte Methode zur Reduzierung Ihrer Fehlerrate und verbessert die Spezifität automatisierter Komponententests.

Hier ist ein Beispiel:

void OuterFunction()
{
    DoSomethingIfPossible();
    DoSomethingNoMatterWhat();
}

void DoSomethingIfPossible()
{
    if (!ok)
    {
        _log.Error("Oops");
        return;
    }
    DoSomething();
}

Option 3. Sprachtrick: Verwenden Sie eine gefälschte Schleife

Ein weiterer häufiger Trick, den ich sehe, ist die Verwendung von while (true) und break, wie in den anderen Antworten gezeigt.

while(true)
{
     if (!ok) break;
     DoSomething();
     break;  //important
}
DoSomethingNoMatterWhat();

Dies ist zwar weniger "ehrlich" als die Verwendung goto, aber es ist weniger anfällig, beim Refactoring durcheinander zu kommen, da es die Grenzen des logischen Umfangs klar markiert. Ein naiver Codierer, der Ihre Etiketten oder gotoAussagen ausschneidet und einfügt, kann große Probleme verursachen! (Und ehrlich gesagt ist das Muster jetzt so verbreitet, dass ich denke, es kommuniziert klar die Absicht und ist daher überhaupt nicht "unehrlich").

Es gibt andere Varianten dieser Optionen. Zum Beispiel könnte man switchanstelle von verwenden while. Jedes Sprachkonstrukt mit einem breakSchlüsselwort würde wahrscheinlich funktionieren.

Option 4. Nutzen Sie den Objektlebenszyklus

Ein anderer Ansatz nutzt den Objektlebenszyklus. Verwenden Sie ein Kontextobjekt, um Ihre Parameter zu übertragen (etwas, das unserem naiven Beispiel verdächtig fehlt), und entsorgen Sie es, wenn Sie fertig sind.

class MyContext
{
   ~MyContext()
   {
        DoSomethingNoMatterWhat();
   }
}

void MainMethod()
{
    MyContext myContext;
    ok = DoSomething(myContext);
    if (!ok)
    {
        _log.Error("Oops");
        return;
    }
    ok = DoSomethingElse(myContext);
    if (!ok)
    {
        _log.Error("Oops");
        return;
    }
    ok = DoSomethingMore(myContext);
    if (!ok)
    {
        _log.Error("Oops");
    }

    //DoSomethingNoMatterWhat will be called when myContext goes out of scope
}

Hinweis: Stellen Sie sicher, dass Sie den Objektlebenszyklus der Sprache Ihrer Wahl verstehen. Damit dies funktioniert, benötigen Sie eine Art deterministische Garbage Collection, dh Sie müssen wissen, wann der Destruktor aufgerufen wird. In einigen Sprachen müssen Sie Disposeanstelle eines Destruktors verwenden.

Option 4.1. Nutzen Sie den Objektlebenszyklus (Wrapper-Muster)

Wenn Sie einen objektorientierten Ansatz verwenden möchten, können Sie dies auch richtig machen. Diese Option verwendet eine Klasse, um die zu bereinigenden Ressourcen sowie die anderen Vorgänge zu "verpacken".

class MyWrapper 
{
   bool DoSomething() {...};
   bool DoSomethingElse() {...}


   void ~MyWapper()
   {
        DoSomethingNoMatterWhat();
   }
}

void MainMethod()
{
    bool ok = myWrapper.DoSomething();
    if (!ok)
        _log.Error("Oops");
        return;
    }
    ok = myWrapper.DoSomethingElse();
    if (!ok)
       _log.Error("Oops");
        return;
    }
}
//DoSomethingNoMatterWhat will be called when myWrapper is destroyed

Stellen Sie erneut sicher, dass Sie Ihren Objektlebenszyklus verstehen.

Option 5. Sprachtrick: Verwenden Sie die Kurzschlussauswertung

Eine andere Technik besteht darin, die Kurzschlussbewertung zu nutzen .

if (DoSomething1() && DoSomething2() && DoSomething3())
{
    DoSomething4();
}
DoSomethingNoMatterWhat();

Diese Lösung nutzt die Arbeitsweise des && Operators. Wenn die linke Seite von && als falsch ausgewertet wird, wird die rechte Seite niemals ausgewertet.

Dieser Trick ist am nützlichsten, wenn kompakter Code erforderlich ist und wenn für den Code wahrscheinlich keine große Wartung erforderlich ist, z. B. wenn Sie einen bekannten Algorithmus implementieren. Für eine allgemeinere Codierung ist die Struktur dieses Codes zu spröde. Selbst eine geringfügige Änderung der Logik kann ein vollständiges Umschreiben auslösen.

Mach einfach

if( executeStepA() && executeStepB() && executeStepC() )
{
    // ...
}
executeThisFunctionInAnyCase();

So einfach ist das.

Aufgrund von drei Änderungen, durch die jede die Frage grundlegend geändert hat (vier, wenn man die Revision auf Version 1 zurückzählt), füge ich das Codebeispiel hinzu, auf das ich antworte:

bool conditionA = executeStepA();
if (conditionA){
    bool conditionB = executeStepB();
    if (conditionB){
        bool conditionC = executeStepC();
        if (conditionC){
            ...
        }
    }
}

executeThisFunctionInAnyCase();

Es gibt tatsächlich eine Möglichkeit, Aktionen in C ++ zu verschieben: Verwenden des Destruktors eines Objekts.

Angenommen, Sie haben Zugriff auf C ++ 11:

class Defer {
public:
    Defer(std::function<void()> f): f_(std::move(f)) {}
    ~Defer() { if (f_) { f_(); } }

    void cancel() { f_ = std::function<void()>(); }

private:
    Defer(Defer const&) = delete;
    Defer& operator=(Defer const&) = delete;

    std::function<void()> f_;
}; // class Defer

Und dann mit diesem Dienstprogramm:

int foo() {
    Defer const defer{&executeThisFunctionInAnyCase}; // or a lambda

    // ...

    if (!executeA()) { return 1; }

    // ...

    if (!executeB()) { return 2; }

    // ...

    if (!executeC()) { return 3; }

    // ...

    return 4;
} // foo

Es gibt eine nette Technik, die keine zusätzliche Wrapper-Funktion mit den return-Anweisungen benötigt (die von Itjax vorgeschriebene Methode). Es wird eine do- while(0)Pseudo-Schleife verwendet. Das while (0)stellt sicher, dass es sich tatsächlich nicht um eine Schleife handelt, sondern nur einmal ausgeführt wird. Die Schleifensyntax ermöglicht jedoch die Verwendung der break-Anweisung.

void foo()
{
  // ...
  do {
      if (!executeStepA())
          break;
      if (!executeStepB())
          break;
      if (!executeStepC())
          break;
  }
  while (0);
  // ...
}

Sie können dies auch tun:

bool isOk = true;
std::vector<bool (*)(void)> funcs; //vector of function ptr

funcs.push_back(&executeStepA);
funcs.push_back(&executeStepB);
funcs.push_back(&executeStepC);
//...

//this will stop at the first false return
for (auto it = funcs.begin(); it != funcs.end() && isOk; ++it) 
    isOk = (*it)();
if (isOk)
 //doSomeStuff
executeThisFunctionInAnyCase();

Auf diese Weise haben Sie eine minimale lineare Wachstumsgröße von +1 Zeile pro Anruf und können problemlos gewartet werden.

EDIT : (Danke @Unda) Kein großer Fan, weil du die Sichtbarkeit verlierst IMO:

bool isOk = true;
auto funcs { //using c++11 initializer_list
    &executeStepA,
    &executeStepB,
    &executeStepC
};

for (auto it = funcs.begin(); it != funcs.end() && isOk; ++it) 
    isOk = (*it)();
if (isOk)
 //doSomeStuff
executeThisFunctionInAnyCase();

Würde das funktionieren? Ich denke, das entspricht Ihrem Code.

bool condition = true; // using only one boolean variable
if (condition) condition = executeStepA();
if (condition) condition = executeStepB();
if (condition) condition = executeStepC();
...
executeThisFunctionInAnyCase();

Angenommen, der gewünschte Code ist so, wie ich ihn derzeit sehe:

bool conditionA = executeStepA();
if (conditionA){
    bool conditionB = executeStepB();
    if (conditionB){
        bool conditionC = executeStepC();
        if (conditionC){
            ...
        }
    }
}    
executeThisFunctionInAnyCase();

Ich würde sagen, dass der richtige Ansatz, da er am einfachsten zu lesen und am einfachsten zu pflegen ist, weniger Einrückungsstufen aufweist, was (derzeit) der erklärte Zweck der Frage ist.

// Pre-declare the variables for the conditions
bool conditionA = false;
bool conditionB = false;
bool conditionC = false;

// Execute each step only if the pre-conditions are met
conditionA = executeStepA();
if (conditionA)
    conditionB = executeStepB();
if (conditionB)
    conditionC = executeStepC();
if (conditionC) {
    ...
}

// Unconditionally execute the 'cleanup' part.
executeThisFunctionInAnyCase();

Dies vermeidet jede Notwendigkeit gotos, Ausnahmen, Dummy - whileSchleifen oder andere schwierigen Konstrukte und einfach wird auf mit der einfachen Arbeit an der Hand.

Könnte die break-Anweisung auf irgendeine Weise verwendet werden?

Vielleicht nicht die beste Lösung, aber Sie können Ihre Anweisungen in eine do .. while (0)Schleife setzen und breakstattdessen Anweisungen verwenden return.

Sie können alle ifBedingungen, die nach Ihren Wünschen formatiert sind, in eine eigene executeThisFunctionInAnyCase()Funktion einfügen und die Funktion bei der Rückgabe ausführen .

Aus dem Basisbeispiel im OP können die Bedingungstests und die Ausführung als solche abgespalten werden.

void InitialSteps()
{
  bool conditionA = executeStepA();
  if (!conditionA)
    return;
  bool conditionB = executeStepB();
  if (!conditionB)
    return;
  bool conditionC = executeStepC();
  if (!conditionC)
    return;
}

Und dann als solche bezeichnet;

InitialSteps();
executeThisFunctionInAnyCase();

Wenn C ++ 11-Lambdas verfügbar sind (es gab kein C ++ 11-Tag im OP, aber sie sind möglicherweise noch eine Option), können wir auf die separate Funktion verzichten und diese in ein Lambda einpacken.

// Capture by reference (variable access may be required)
auto initialSteps = [&]() {
  // any additional code
  bool conditionA = executeStepA();
  if (!conditionA)
    return;
  // any additional code
  bool conditionB = executeStepB();
  if (!conditionB)
    return;
  // any additional code
  bool conditionC = executeStepC();
  if (!conditionC)
    return;
};

initialSteps();
executeThisFunctionInAnyCase();

Wenn Sie Loops nicht mögen gotound nicht mögen do { } while (0);und C ++ verwenden möchten, können Sie auch ein temporäres Lambda verwenden, um den gleichen Effekt zu erzielen.

[&]() { // create a capture all lambda
  if (!executeStepA()) { return; }
  if (!executeStepB()) { return; }
  if (!executeStepC()) { return; }
}(); // and immediately call it

executeThisFunctionInAnyCase();

Die Ketten von IF / ELSE in Ihrem Code sind nicht das Sprachproblem, sondern das Design Ihres Programms. Wenn Sie in der Lage sind, Ihr Programm neu zu faktorisieren oder neu zu schreiben, würde ich vorschlagen, dass Sie in Design Patterns ( http://sourcemaking.com/design_patterns ) nach einer besseren Lösung suchen.

Wenn Sie viele IFs und andere in Ihrem Code sehen, ist dies normalerweise eine Gelegenheit, das Strategie-Design-Muster ( http://sourcemaking.com/design_patterns/strategy/c-sharp-dot-net ) oder eine Kombination zu implementieren von anderen Mustern.

Ich bin mir sicher, dass es Alternativen gibt, um eine lange Liste von if / else zu schreiben, aber ich bezweifle, dass sie irgendetwas ändern werden, außer dass die Kette für Sie hübsch aussieht (jedoch liegt die Schönheit im Auge des Betrachters immer noch für Code auch:-) ) . Sie sollten sich Sorgen machen über Dinge wie (in 6 Monaten, wenn ich einen neuen Zustand habe und mich an nichts über diesen Code erinnere, kann ich ihn einfach hinzufügen? Oder was ist, wenn sich die Kette ändert, wie schnell und fehlerfrei werde ich es umsetzen)

Du machst das einfach ..

coverConditions();
executeThisFunctionInAnyCase();

function coverConditions()
 {
 bool conditionA = executeStepA();
 if (!conditionA) return;
 bool conditionB = executeStepB();
 if (!conditionB) return;
 bool conditionC = executeStepC();
 if (!conditionC) return;
 }

99 mal von 100, das ist der einzige Weg, es zu tun.

Versuchen Sie niemals, etwas "Kniffliges" im Computercode zu tun.

Ich bin mir übrigens ziemlich sicher, dass das Folgende die eigentliche Lösung ist, die Sie sich vorgestellt haben ...

Die continue- Anweisung ist für die algorithmische Programmierung von entscheidender Bedeutung. (Ebenso wie die goto-Anweisung bei der algorithmischen Programmierung von entscheidender Bedeutung ist.)

In vielen Programmiersprachen können Sie dies tun:

-(void)_testKode
    {
    NSLog(@"code a");
    NSLog(@"code b");
    NSLog(@"code c\n");

    int x = 69;

    {

    if ( x == 13 )
        {
        NSLog(@"code d---\n");
        continue;
        }

    if ( x == 69 )
        {
        NSLog(@"code e---\n");
        continue;
        }

    if ( x == 13 )
        {
        NSLog(@"code f---\n");
        continue;
        }

    }

    NSLog(@"code g");
    }

(Beachten Sie zunächst: Nackte Blöcke wie dieses Beispiel sind ein kritischer und wichtiger Bestandteil beim Schreiben von schönem Code, insbesondere wenn Sie sich mit "algorithmischer" Programmierung beschäftigen.)

Auch das ist genau das, was Sie in Ihrem Kopf hatten, nicht wahr? Und das ist die schöne Art, es zu schreiben, also hast du gute Instinkte.

Tragischerweise gibt es in der aktuellen Version von Objective-C (abgesehen davon - ich weiß leider nichts über Swift) eine risikoreiche Funktion, bei der überprüft wird, ob der umschließende Block eine Schleife ist.

Hier erfahren Sie, wie Sie das umgehen können ...

-(void)_testKode
    {
    NSLog(@"code a");
    NSLog(@"code b");
    NSLog(@"code c\n");

    int x = 69;

    do{

    if ( x == 13 )
        {
        NSLog(@"code d---\n");
        continue;
        }

    if ( x == 69 )
        {
        NSLog(@"code e---\n");
        continue;
        }

    if ( x == 13 )
        {
        NSLog(@"code f---\n");
        continue;
        }

    }while(false);

    NSLog(@"code g");
    }

Also vergiss das nicht ..

do {} while (false);

bedeutet nur "mache diesen Block einmal".

Das heißt, es gibt absolut keinen Unterschied zwischen Schreiben do{}while(false);und einfachem Schreiben {}.

Dies funktioniert jetzt perfekt wie Sie wollten ... hier ist die Ausgabe ...

Es ist also möglich, dass Sie den Algorithmus so in Ihrem Kopf sehen. Sie sollten immer versuchen zu schreiben, was in Ihrem Kopf ist. (Besonders wenn du nicht nüchtern bist, denn dann kommt das Hübsche raus! :))

In "algorithmischen" Projekten, in denen dies häufig vorkommt, haben wir in Ziel-c immer ein Makro wie ...

#define RUNONCE while(false)

... also dann kannst du das machen ...

-(void)_testKode
    {
    NSLog(@"code a");
    int x = 69;

    do{
    if ( x == 13 )
        {
        NSLog(@"code d---\n");
        continue;
        }
    if ( x == 69 )
        {
        NSLog(@"code e---\n");
        continue;
        }
    if ( x == 13 )
        {
        NSLog(@"code f---\n");
        continue;
        }
    }RUNONCE

    NSLog(@"code g");
    }

Es gibt zwei Punkte:

a, obwohl es dumm ist, dass objectiv-c die Art des Blocks überprüft, in dem sich eine continue-Anweisung befindet, ist es beunruhigend, "das zu bekämpfen". Es ist also eine schwierige Entscheidung.

b, gibt es die Frage, ob Sie im Beispiel diesen Block einrücken sollten? Ich verliere den Schlaf wegen solcher Fragen, daher kann ich nicht raten.

Ich hoffe es hilft.

Lassen Sie Ihre Ausführungsfunktionen eine Ausnahme auslösen, wenn sie fehlschlagen, anstatt false zurückzugeben. Dann könnte Ihr Anrufcode folgendermaßen aussehen:

try {
    executeStepA();
    executeStepB();
    executeStepC();
}
catch (...)

Natürlich gehe ich davon aus, dass in Ihrem ursprünglichen Beispiel der Ausführungsschritt nur dann false zurückgeben würde, wenn innerhalb des Schritts ein Fehler auftritt.

Viele gute Antworten bereits, aber die meisten scheinen einen Teil (zugegebenermaßen sehr wenig) der Flexibilität zu beeinträchtigen. Ein gängiger Ansatz, der diesen Kompromiss nicht erfordert, ist das Hinzufügen einer Status- / Keep-Going- Variablen. Der Preis ist natürlich ein zusätzlicher Wert, den Sie im Auge behalten sollten:

bool ok = true;
bool conditionA = executeStepA();
// ... possibly edit conditionA, or just ok &= executeStepA();
ok &= conditionA;

if (ok) {
    bool conditionB = executeStepB();
    // ... possibly do more stuff
    ok &= conditionB;
}
if (ok) {
    bool conditionC = executeStepC();
    ok &= conditionC;
}
if (ok && additionalCondition) {
    // ...
}

executeThisFunctionInAnyCase();
// can now also:
return ok;

Wenn Sie in C ++ (die Frage ist sowohl mit C als auch mit C ++ gekennzeichnet) die Funktionen nicht ändern können, um Ausnahmen zu verwenden, können Sie den Ausnahmemechanismus trotzdem verwenden, wenn Sie eine kleine Hilfsfunktion wie schreiben

struct function_failed {};
void attempt(bool retval)
{
  if (!retval)
    throw function_failed(); // or a more specific exception class
}

Dann könnte Ihr Code wie folgt lauten:

try
{
  attempt(executeStepA());
  attempt(executeStepB());
  attempt(executeStepC());
}
catch (function_failed)
{
  // -- this block intentionally left empty --
}

executeThisFunctionInAnyCase();

Wenn Sie sich für ausgefallene Syntax interessieren, können Sie sie stattdessen über eine explizite Besetzung zum Laufen bringen:

struct function_failed {};
struct attempt
{
  attempt(bool retval)
  {
    if (!retval)
      throw function_failed();
  }
};

Dann können Sie Ihren Code als schreiben

try
{
  (attempt) executeStepA();
  (attempt) executeStepB();
  (attempt) executeStepC();
}
catch (function_failed)
{
  // -- this block intentionally left empty --
}

executeThisFunctionInAnyCase();

Wenn Ihr Code so einfach wie Ihr Beispiel ist und Ihre Sprache Kurzschlussauswertungen unterstützt, können Sie Folgendes versuchen:

StepA() && StepB() && StepC() && StepD();
DoAlways();

Wenn Sie Argumente an Ihre Funktionen übergeben und andere Ergebnisse zurückerhalten, sodass Ihr Code nicht auf die vorherige Weise geschrieben werden kann, sind viele der anderen Antworten besser für das Problem geeignet.

Für C ++ 11 und höher könnte ein guter Ansatz darin bestehen, ein Scope-Exit- System zu implementieren, das dem Scope-Exit- Mechanismus (Exit- Mechanismus ) von D ähnelt .

Eine Möglichkeit zur Implementierung ist die Verwendung von C ++ 11-Lambdas und einigen Hilfsmakros:

template<typename F> struct ScopeExit 
{
    ScopeExit(F f) : fn(f) { }
    ~ScopeExit() 
    { 
         fn();
    }

    F fn;
};

template<typename F> ScopeExit<F> MakeScopeExit(F f) { return ScopeExit<F>(f); };

#define STR_APPEND2_HELPER(x, y) x##y
#define STR_APPEND2(x, y) STR_APPEND2_HELPER(x, y)

#define SCOPE_EXIT(code)\
    auto STR_APPEND2(scope_exit_, __LINE__) = MakeScopeExit([&](){ code })

Auf diese Weise können Sie frühzeitig von der Funktion zurückkehren und sicherstellen, dass der von Ihnen definierte Bereinigungscode immer beim Beenden des Bereichs ausgeführt wird:

SCOPE_EXIT(
    delete pointerA;
    delete pointerB;
    close(fileC); );

if (!executeStepA())
    return;

if (!executeStepB())
    return;

if (!executeStepC())
    return;

Die Makros sind wirklich nur Dekoration. MakeScopeExit()kann direkt verwendet werden.

Warum gibt niemand die einfachste Lösung? : D.

Wenn alle Ihre Funktionen dieselbe Signatur haben, können Sie dies folgendermaßen tun (für die Sprache C):

bool (*step[])() = {
    &executeStepA,
    &executeStepB,
    &executeStepC,
    ... 
};

for (int i = 0; i < numberOfSteps; i++) {
    bool condition = step[i]();

    if (!condition) {
        break;
    }
}

executeThisFunctionInAnyCase();

Für eine saubere C ++ - Lösung sollten Sie eine Schnittstellenklasse erstellen, die eine Ausführungsmethode enthält und Ihre Schritte in Objekte einschließt.
Dann sieht die obige Lösung folgendermaßen aus:

Step *steps[] = {
    stepA,
    stepB,
    stepC,
    ... 
};

for (int i = 0; i < numberOfSteps; i++) {
    Step *step = steps[i];

    if (!step->execute()) {
        break;
    }
}

executeThisFunctionInAnyCase();

Angenommen, Sie benötigen keine einzelnen Bedingungsvariablen. Wenn Sie die Tests invertieren und das else-falthrough als "ok" -Pfad verwenden, erhalten Sie eine vertikalere Menge von if / else-Anweisungen:

bool failed = false;

// keep going if we don't fail
if (failed = !executeStepA())      {}
else if (failed = !executeStepB()) {}
else if (failed = !executeStepC()) {}
else if (failed = !executeStepD()) {}

runThisFunctionInAnyCase();

Das Weglassen der fehlgeschlagenen Variablen macht den Code IMO etwas zu dunkel.

Das Deklarieren der Variablen im Inneren ist in Ordnung, keine Sorge um = vs ==.

// keep going if we don't fail
if (bool failA = !executeStepA())      {}
else if (bool failB = !executeStepB()) {}
else if (bool failC = !executeStepC()) {}
else if (bool failD = !executeStepD()) {}
else {
     // success !
}

runThisFunctionInAnyCase();

Das ist dunkel, aber kompakt:

// keep going if we don't fail
if (!executeStepA())      {}
else if (!executeStepB()) {}
else if (!executeStepC()) {}
else if (!executeStepD()) {}
else { /* success */ }

runThisFunctionInAnyCase();

Dies sieht aus wie eine Zustandsmaschine, was praktisch ist, da Sie sie einfach mit einem Zustandsmuster implementieren können .

In Java würde es ungefähr so ​​aussehen:

interface StepState{
public StepState performStep();
}

Eine Implementierung würde wie folgt funktionieren:

class StepA implements StepState{ 
    public StepState performStep()
     {
         performAction();
         if(condition) return new StepB()
         else return null;
     }
}

Und so weiter. Dann können Sie die große if-Bedingung durch Folgendes ersetzen:

Step toDo = new StepA();
while(toDo != null)
      toDo = toDo.performStep();
executeThisFunctionInAnyCase();

Wie Rommik erwähnte, könnten Sie hierfür ein Entwurfsmuster anwenden, aber ich würde das Decorator-Muster anstelle der Strategie verwenden, da Sie Anrufe verketten möchten. Wenn der Code einfach ist, würde ich eine der gut strukturierten Antworten verwenden, um eine Verschachtelung zu verhindern. Wenn es jedoch komplex ist oder eine dynamische Verkettung erfordert, ist das Decorator-Muster eine gute Wahl. Hier ist ein yUML-Klassendiagramm :

Hier ist ein Beispiel für ein LinqPad C # -Programm:

void Main()
{
    IOperation step = new StepC();
    step = new StepB(step);
    step = new StepA(step);
    step.Next();
}

public interface IOperation 
{
    bool Next();
}

public class StepA : IOperation
{
    private IOperation _chain;
    public StepA(IOperation chain=null)
    {
        _chain = chain;
    }

    public bool Next() 
    {
        bool localResult = false;
        //do work
        //...
        // set localResult to success of this work
        // just for this example, hard coding to true
        localResult = true;
        Console.WriteLine("Step A success={0}", localResult);

        //then call next in chain and return
        return (localResult && _chain != null) 
            ? _chain.Next() 
            : true;
    }
}

public class StepB : IOperation
{
    private IOperation _chain;
    public StepB(IOperation chain=null)
    {
        _chain = chain;
    }

    public bool Next() 
    {   
        bool localResult = false;

        //do work
        //...
        // set localResult to success of this work
        // just for this example, hard coding to false, 
            // to show breaking out of the chain
        localResult = false;
        Console.WriteLine("Step B success={0}", localResult);

        //then call next in chain and return
        return (localResult && _chain != null) 
            ? _chain.Next() 
            : true;
    }
}

public class StepC : IOperation
{
    private IOperation _chain;
    public StepC(IOperation chain=null)
    {
        _chain = chain;
    }

    public bool Next() 
    {
        bool localResult = false;
        //do work
        //...
        // set localResult to success of this work
        // just for this example, hard coding to true
        localResult = true;
        Console.WriteLine("Step C success={0}", localResult);
        //then call next in chain and return
        return (localResult && _chain != null) 
            ? _chain.Next() 
            : true;
    }
}

Das beste Buch zum Lesen von Designmustern, IMHO, ist Head First Design Patterns .

Mehrere Antworten deuteten auf ein Muster hin, das ich oft gesehen und verwendet habe, insbesondere bei der Netzwerkprogrammierung. In Netzwerkstapeln gibt es häufig eine lange Folge von Anforderungen, von denen jede fehlschlagen kann und den Prozess stoppt.

Das übliche Muster war zu verwenden do { } while (false);

Ich habe ein Makro verwendet while(false), um es zu erstellen. do { } once;Das übliche Muster war:

do
{
    bool conditionA = executeStepA();
    if (! conditionA) break;
    bool conditionB = executeStepB();
    if (! conditionB) break;
    // etc.
} while (false);

Dieses Muster war relativ einfach zu lesen und ermöglichte die Verwendung von Objekten, die ordnungsgemäß zerstört und mehrere Rückgaben vermieden wurden, was das Schritt- und Debugging etwas erleichterte.

Um die C ++ 11-Antwort von Mathieu zu verbessern und die Laufzeitkosten zu vermeiden, die durch die Verwendung von entstehen std::function, würde ich empfehlen, Folgendes zu verwenden

template<typename functor>
class deferred final
{
public:
    template<typename functor2>
    explicit deferred(functor2&& f) : f(std::forward<functor2>(f)) {}
    ~deferred() { this->f(); }

private:
    functor f;
};

template<typename functor>
auto defer(functor&& f) -> deferred<typename std::decay<functor>::type>
{
    return deferred<typename std::decay<functor>::type>(std::forward<functor>(f));
}

Diese einfache Vorlagenklasse akzeptiert jeden Funktor, der ohne Parameter aufgerufen werden kann, und zwar ohne dynamische Speicherzuweisungen und entspricht daher besser dem Abstraktionsziel von C ++ ohne unnötigen Overhead. Die zusätzliche Funktionsvorlage soll die Verwendung durch Ableiten von Vorlagenparametern vereinfachen (was für Klassenvorlagenparameter nicht verfügbar ist).

Anwendungsbeispiel:

auto guard = defer(executeThisFunctionInAnyCase);
bool conditionA = executeStepA();
if (!conditionA) return;
bool conditionB = executeStepB();
if (!conditionB) return;
bool conditionC = executeStepC();
if (!conditionC) return;

Genau wie Mathieus Antwort ist diese Lösung völlig ausnahmesicher und executeThisFunctionInAnyCasewird in jedem Fall aufgerufen. Sollte sich executeThisFunctionInAnyCaseselbst werfen, werden Destruktoren implizit markiert noexceptund daher wird ein Aufruf von std::terminateausgegeben, anstatt zu bewirken, dass beim Abwickeln des Stapels eine Ausnahme ausgelöst wird.

Anscheinend möchten Sie Ihren gesamten Anruf von einem einzigen Block aus erledigen. Wie andere vorgeschlagen haben, sollten Sie entweder eine whileSchleife verwenden und breakeine neue Funktion verwenden, die Sie verlassen können return(möglicherweise sauberer).

Ich persönlich verbanne goto, auch für den Funktionsausgang. Sie sind beim Debuggen schwerer zu erkennen.

Eine elegante Alternative, die für Ihren Workflow funktionieren sollte, besteht darin, ein Funktionsarray zu erstellen und dieses zu iterieren.

const int STEP_ARRAY_COUNT = 3;
bool (*stepsArray[])() = {
   executeStepA, executeStepB, executeStepC
};

for (int i=0; i<STEP_ARRAY_COUNT; ++i) {
    if (!stepsArray[i]()) {
        break;
    }
}

executeThisFunctionInAnyCase();

Da Sie zwischen den Ausführungen auch einen [... Codeblock ...] haben , haben Sie vermutlich Speicherzuweisung oder Objektinitialisierungen. Auf diese Weise müssen Sie sich darum kümmern, alles zu bereinigen, was Sie bereits beim Beenden initialisiert haben, und es auch bereinigen, wenn Sie auf ein Problem stoßen und eine der Funktionen false zurückgibt.

In diesem Fall war das Beste, was ich in meiner Erfahrung (als ich mit CryptoAPI arbeitete) hatte, das Erstellen kleiner Klassen. Im Konstruktor initialisieren Sie Ihre Daten, im Destruktor initialisieren Sie sie nicht. Jede nächste Funktionsklasse muss der vorherigen Funktionsklasse untergeordnet sein. Wenn etwas schief gelaufen ist - Ausnahme auslösen.

class CondA
{
public:
    CondA() { 
        if (!executeStepA()) 
            throw int(1);
        [Initialize data]
    }
    ~CondA() {        
        [Clean data]
    }
    A* _a;
};

class CondB : public CondA
{
public:
    CondB() { 
        if (!executeStepB()) 
            throw int(2);
        [Initialize data]
    }
    ~CondB() {        
        [Clean data]
    }
    B* _b;
};

class CondC : public CondB
{
public:
    CondC() { 
        if (!executeStepC()) 
            throw int(3);
        [Initialize data]
    }
    ~CondC() {        
        [Clean data]
    }
    C* _c;
};

Und dann müssen Sie in Ihrem Code nur noch anrufen:

shared_ptr<CondC> C(nullptr);
try{
    C = make_shared<CondC>();
}
catch(int& e)
{
    //do something
}
if (C != nullptr)
{
   C->a;//work with
   C->b;//work with
   C->c;//work with
}
executeThisFunctionInAnyCase();

Ich denke, es ist die beste Lösung, wenn jeder Aufruf von ConditionX etwas initialisiert, Speicher usw. zuweist. Am besten stellen Sie sicher, dass alles bereinigt wird.

Ein interessanter Weg ist, mit Ausnahmen zu arbeiten.

try
{
    executeStepA();//function throws an exception on error
    ......
}
catch(...)
{
    //some error handling
}
finally
{
    executeThisFunctionInAnyCase();
}

Wenn Sie solchen Code schreiben, gehen Sie irgendwie in die falsche Richtung. Ich werde es nicht als "das Problem" ansehen, einen solchen Code zu haben, sondern eine so chaotische "Architektur".

Tipp: Besprechen Sie diese Fälle mit einem erfahrenen Entwickler, dem Sie vertrauen ;-)

Eine andere do - whileAnsatzschleife, obwohl sie bereits erwähnt wurde, gab es kein Beispiel dafür, das zeigen würde, wie sie aussieht:

do
{
    if (!executeStepA()) break;
    if (!executeStepB()) break;
    if (!executeStepC()) break;
    ...

    break; // skip the do-while condition :)
}
while (0);

executeThisFunctionInAnyCase();

_{(Nun, es gibt bereits eine Antwort mit whileSchleife, aber die do - whileSchleife prüft nicht redundant (am Anfang) auf wahr, sondern am Ende xD (dies kann jedoch übersprungen werden)).}