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

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

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

Try to extract the code into a separate function (or perhaps more than one). Then return from the function if the check fails. If it's too tightly coupled with the surrounding code to do that, and you can't find a way to reduce the coupling, look at the code after this block. Presumably, it cleans up some resources used by the function. Try to manage these resources using an RAII object; then replace each dodgy break with return (or throw, if that's more appropriate) and let the object's destructor clean up for you. If the program flow is (necessarily) so squiggly that you really need a goto, then use that rather than giving it a weird disguise. If you have coding rules that blindly forbid goto, and you really can't simplify the program flow, then you'll probably have to disguise it with your do hack.

对我来说，当(0)是好的时候做{…}。如果您不想看到do{…}while(0)，您可以为它们定义替代关键字。

例子:

SomeUtilities.hpp:

#define BEGIN_TEST do{
#define END_TEST }while(0);

SomeSourceFile.cpp:

BEGIN_TEST
   if(!condition1) break;
   if(!condition2) break;
   if(!condition3) break;
   if(!condition4) break;
   if(!condition5) break;
   
   //processing code here

END_TEST

我认为编译器将在二进制版本的do{…}while(0)中删除不必要的while(0)条件，并将断点转换为无条件跳转。您可以检查它的汇编语言版本来确定。

使用goto还可以生成更简洁的代码，并且使用条件-然后跳转的逻辑非常简单。您可以执行以下操作:

{
   if(!condition1) goto end_blahblah;
   if(!condition2) goto end_blahblah;
   if(!condition3) goto end_blahblah;
   if(!condition4) goto end_blahblah;
   if(!condition5) goto end_blahblah;
   
   //processing code here

 }end_blah_blah:;  //use appropriate label here to describe...
                   //  ...the whole code inside the block.
 

注意标签放在结束}之后。这是避免一个可能的问题，在goto中，不小心将代码放在中间，因为你没有看到标签。现在就像do{…}while(0)没有条件代码。

为了让代码更清晰，更容易理解，你可以这样做:

SomeUtilities.hpp:

#define BEGIN_TEST {
#define END_TEST(_test_label_) }_test_label_:;
#define FAILED(_test_label_) goto _test_label_

SomeSourceFile.cpp:

BEGIN_TEST
   if(!condition1) FAILED(NormalizeData);
   if(!condition2) FAILED(NormalizeData);
   if(!condition3) FAILED(NormalizeData);
   if(!condition4) FAILED(NormalizeData);
   if(!condition5) FAILED(NormalizeData);

END_TEST(NormalizeData)

有了这个，你可以做嵌套块，并指定你想要退出/跳出的位置。

BEGIN_TEST
   if(!condition1) FAILED(NormalizeData);
   if(!condition2) FAILED(NormalizeData);

   BEGIN_TEST
      if(!conditionAA) FAILED(DecryptBlah);
      if(!conditionBB) FAILED(NormalizeData);   //Jump out to the outmost block
      if(!conditionCC) FAILED(DecryptBlah);
  
      // --We can now decrypt and do other stuffs.

   END_TEST(DecryptBlah)

   if(!condition3) FAILED(NormalizeData);
   if(!condition4) FAILED(NormalizeData);

   // --other code here

   BEGIN_TEST
      if(!conditionA) FAILED(TrimSpaces);
      if(!conditionB) FAILED(TrimSpaces);
      if(!conditionC) FAILED(NormalizeData);   //Jump out to the outmost block
      if(!conditionD) FAILED(TrimSpaces);

      // --We can now trim completely or do other stuffs.

   END_TEST(TrimSpaces)

   // --Other code here...

   if(!condition5) FAILED(NormalizeData);

   //Ok, we got here. We can now process what we need to process.

END_TEST(NormalizeData)

杂乱的代码不是goto的错，而是程序员的错。不使用goto仍然可以生成意大利面条代码。

如果你不需要在执行过程中引入局部变量，那么你通常可以将其平化:

if (check()) {
  doStuff();
}  
if (stillOk()) {
  doMoreStuff();
}
if (amIStillReallyOk()) {
  doEvenMore();
}

// edit 
doThingsAtEndAndReportErrorStatus()

有些时候，使用goto实际上是正确的答案——至少对那些没有在宗教信仰中长大的人来说，“不管问题是什么，goto永远都不是答案”——这是其中的一个例子。

此代码使用了do{…}, (0);唯一的目的就是把一个傻瓜打扮成休息的样子。如果你打算使用goto，那就公开使用它。让代码更难阅读是没有意义的。

一种特殊的情况是当你有很多代码和相当复杂的条件时:

void func()
{
   setup of lots of stuff
   ...
   if (condition)
   {
      ... 
      ...
      if (!other condition)
      {
          ...
          if (another condition)
          {
              ... 
              if (yet another condition)
              {
                  ...
                  if (...)
                     ... 
              }
          }
      }
  .... 

  }
  finish up. 
}

没有如此复杂的逻辑，实际上可以更清楚地表明代码是正确的。

void func()
{
   setup of lots of stuff
   ...
   if (!condition)
   {
      goto finish;
   }
   ... 
   ...
   if (other condition)
   {
      goto finish;
   }
   ...
   if (!another condition)
   {
      goto finish;
   }
   ... 
   if (!yet another condition)
   {
      goto finish;
   }
   ... 
   .... 
   if (...)
         ...    // No need to use goto here. 
 finish:
   finish up. 
}

编辑:澄清一下，我绝不是建议使用goto作为通用解决方案。但在某些情况下，goto是比其他解决方案更好的解决方案。

例如，想象一下，我们正在收集一些数据，测试的不同条件是某种“这是正在收集的数据的结束”——这取决于某种“继续/结束”标记，这些标记根据您在数据流中的位置而变化。

现在，当我们完成之后，我们需要将数据保存到一个文件中。

是的，通常有其他解决方案可以提供合理的解决方案，但并不总是如此。

我不是c++程序员，所以我不会在这里写任何代码，但到目前为止还没有人提到面向对象的解决方案。下面是我的猜测:

拥有一个通用接口，该接口提供了一个方法来评估单个条件。现在，您可以在包含有问题的方法的对象中使用这些条件的实现列表。遍历列表并计算每个条件，如果其中一个条件失败，可能会提前爆发。

这样的设计很好地遵循了开/闭原则，因为在初始化包含相关方法的对象时，可以很容易地添加新的条件。您甚至可以向接口添加第二个方法，该方法用于条件评估，返回条件的描述。这可以用于自文档系统。

但是，缺点是由于使用了更多的对象和遍历列表，所涉及的开销稍微多一些。