如果根据故障发生的位置需要不同的清理步骤，另一个模式很有用:

    private ResultCode DoEverything()
    {
        ResultCode processResult = ResultCode.FAILURE;
        if (DoStep1() != ResultCode.SUCCESSFUL)
        {
            Step1FailureCleanup();
        }
        else if (DoStep2() != ResultCode.SUCCESSFUL)
        {
            Step2FailureCleanup();
            processResult = ResultCode.SPECIFIC_FAILURE;
        }
        else if (DoStep3() != ResultCode.SUCCESSFUL)
        {
            Step3FailureCleanup();
        }
        ...
        else
        {
            processResult = ResultCode.SUCCESSFUL;
        }
        return processResult;
    }

首先，一个简短的例子来说明为什么goto不是一个好的c++解决方案:

struct Bar {
    Bar();
};

extern bool check();

void foo()
{
    if (!check())
       goto out;

    Bar x;

    out:
}

试着把它编译成一个object文件，看看会发生什么。然后尝试等价的do+ break + while(0)。

这是题外话。主要观点如下。

如果整个函数失败，这些小块的代码通常需要某种类型的清理。当您“展开”部分完成的计算时，这些清理通常希望以与块本身相反的顺序发生。

获得这些语义的一个选项是RAII;参见@utnapistim的回答。c++保证自动析构函数以与构造函数相反的顺序运行，这自然提供了一个“unwind”。

但这需要大量的RAII类。有时一个更简单的选择是使用堆栈:

bool calc1()
{
    if (!check())
        return false;

    // ... Do stuff1 here ...

    if (!calc2()) {
        // ... Undo stuff1 here ...
        return false;
    }

    return true;
}

bool calc2()
{
    if (!check())
        return false;

    // ... Do stuff2 here ...

    if (!calc3()) {
        // ... Undo stuff2 here ...
        return false;
    }

    return true;
}

.．.等等。这很容易审计，因为它把“撤销”代码放在“做”代码旁边。简单的审计是好的。它还使控制流非常清晰。对于C来说，这也是一个有用的模式。

它可能要求calc函数接受大量参数，但如果您的类/结构具有良好的内聚性，这通常不是问题。(也就是说，属于一起的东西生活在一个对象中，所以这些函数可以作为指向少量对象的指针或引用，但仍然可以做很多有用的工作。)

类似于dasblinkenlight的答案，但避免了if语句中的赋值，这可能会被代码评审员“修复”:

bool goOn = check0();
if (goOn) {
    ...
    goOn = check1();
}
if (goOn) {
    ...
    goOn = check2();
}
if (goOn) {
    ...
}

...

当一个步骤的结果需要在下一步之前检查时，我使用这种模式，这与所有检查都可以在前面用一个大if(check1() && check2()…类型的模式。

当然不是答案，而是一个答案(为了完整起见)

而不是:

do {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

你可以这样写:

switch (0) {
case 0:
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

这仍然是一个伪装的goto，但至少它不再是一个循环。这意味着你不需要非常仔细地检查是否有一些继续隐藏在块的某处。

构造也非常简单，您可以希望编译器会优化它。

正如@jamesdlin所建议的，你甚至可以把它隐藏在一个宏后面

#define BLOC switch(0) case 0:

然后像这样使用它

BLOC {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

这是可能的，因为C语言语法期望在开关之后有一个语句，而不是一个括号中的块，并且您可以在该语句之前放置一个case标签。到目前为止，我还没有看到允许这样做的意义，但在这种特殊情况下，将开关隐藏在一个漂亮的宏后面是很方便的。

如果你的代码有一个很长的If ..else If ..else语句块，你可以尝试在函子或函数指针的帮助下重写整个块。这可能并不总是正确的解决方案，但通常是正确的。

http://www.cprogramming.com/tutorial/functors-function-objects-in-c++.html

如果对所有错误使用相同的错误处理程序，并且每一步返回一个bool值指示成功:

if(
    DoSomething() &&
    DoSomethingElse() &&
    DoAThirdThing() )
{
    // do good condition action
}
else
{
    // handle error
}

(类似于tyzoid的回答，但条件是动作，&&防止在第一次失败后发生额外的动作。)