如何在 Java 中管理复杂的流程控制？

Question

我在这里研究 Java 流控制和异常处理有一段时间了，并且有这些普遍接受的规则：

1. 不要使用异常处理进行流控制，
2. 避免检查异常，除非客户端期望恢复（这是一个很好的方式来表达你强制客户端处理异常，以便他们也可以尝试从中恢复？）

以及我尝试遵循的一般规则：

1. 如果 doSomething() 无法“做某事”，则应该让调用者意识到这一点
2. 方法应该关注做一件事，

这在某些情况下会导致糟糕的组合。我发现我在方法中捕获了已检查的异常，并在各处返回布尔值，并且不断地必须检查连续的调用，做出这样的事情：

if(doA()){
  if(doB()){
    if(doC()){ 
      // only here do I know it's good
    }else{
      // I know C failed
    }
  }else{
    // I know B failed
  }
}else{
  // I know A failed
}

我在某些部分得到了 5-6 个嵌套的 if-else，这非常难看。更不用说管理一堆布尔变量来跟踪哪些有效，哪些无效。

有什么建议吗？这是一个可以接受“goto”的地方吗？

Answer 1

您应该查看 doA()、doB() 和 doC()。如果它们不太可能失败，则在失败时抛出异常。

try {
  doA();
  doB();
  doC();
} catch (FailureException e) {
  // handle failure
}

不合理失败的例子比比皆是，IOException、IllegalParameterException等。

如果它们很可能失败，那么

if (!doA()) {
  // handle A's failure
  return;
}
if (!doB()) {
  // handle B's failure
  return;
}
if (!doC()) {
  // handle C's failure
  return;
}

合理失败的例子在Java中不太被强调。一些示例包括当没有更多内容可供读取时，read() 返回 -1。如果您的 doA() 的名称实际上更接近于 attemptA()，那么可能会返回一个 boolean 来指示尝试是否成功。想想 Collections 接口中的 add(...) 和 addAll(...)，它们返回 true 如果生成的 Collection 被修改。

在大多数语言中，传统的 goto 并不是一个好的选择，因为在检查代码时，几乎不可能知道代码“来自”哪里。由于缺乏对进入goto之前的状态的了解，因此无法保证进入goto块之前的一致环境。顺便说一句，这就是为什么传统的 goto 在 Java 中不可用，而只有有限的延续 goto 可用。

要从嵌套不良的结构转换为嵌套较少的结构，请使用一些重构技术：

if(doA()){
  if (doB()) {
    if (doC()) { 
      // only here do I know it's good
    } else {
      // I know C failed
    }
  } else {
    // I know B failed
  }
} else {
  // I know A failed
}
return;

相当于 相当于

if (doA()) {
  if (doB()) {
    if (doC()) { 
      // only here do I know it's good
    } else {
      // I know C failed
    }
  } else {
    // I know B failed
  }
  return;
} else {
  // I know A failed
  return;
}

如果

if (!doA()) {
  // I know A failed
  return;
} else {
  if (doB()) {
    if (doC()) { 
      // only here do I know it's good
    } else {
      // I know C failed
    }
  } else {
    // I know B failed
  }
  return;
}

“我知道 A 失败”中的代码包含返回，则您无需担心代码在条件 doA() 为 true 的情况下，落入下面的代码；这样你就可以提升较低的块，如下所示：

if (!doA()) {
  // I know A failed
  return;
}
if (doB()) {
  if (doC()) { 
    // only here do I know it's good
  } else {
    // I know C failed
  }
} else {
  // I know B failed
}
return;

Answer 2

是的。使用异常而不是返回代码。如果您愿意，您可以将异常包装在自己的异常中。

在异常情况下使用异常进行流量控制是完全合理的。通常的建议是避免将它们用于普通流量控制。

Answer 3

我认为你的规则“除非客户端希望恢复，否则不要使用检查异常”是错误的。让调用者根本不恢复，而是将异常传递给调用者，可能会将异常转换为其他内容，这是很常见的。

Answer 4

我会使用状态模式。这样做可以使您的代码更更易于阅读，因为您只能看到从当前状态可以进入哪些可能的状态。