什么时候可以对业务逻辑使用异常处理？

我认为，作为 Java（或许还有任何具有异常处理的语言）的一般规则，人们应该尽量避免使用异常处理来实际处理业务逻辑。一般来说，如果预计会发生某种情况，那么应该比依赖异常处理来更直接地检查并处理它。例如，以下行为不被视为良好做法：

try{
  _map.put(myKey, myValue);
} catch(NullPointerException e){
  _map = new HashMap<String, String>();
}

相反，延迟初始化应该更像这样完成：

if(_map == null){
  _map = new HashMap<String, String>();
}
_map.put(myKey, myValue);

当然，可能有比简单处理延迟初始化更复杂的逻辑。因此，考虑到这种类型的事情通常不受欢迎……什么时候（如果有的话）依靠发生的异常来实现某些业务逻辑是一个好主意？如果有人觉得不得不使用这种方法，那么可以准确地说，这确实凸显了所使用的 API 的弱点吗？

每当异常可以预见但无法避免时。

比如说，如果您依赖某种外部 API 来解析数据，并且该 API 提供了解析方法，但没有说明给定的输入是否可以解析（或者解析是否成功取决于因素） （但 API 不提供适当的函数调用），并且当无法解析输入时，解析方法会抛出异常。

通过正确设计的 API，这应该归结为“几乎从不”到“从不”范围内的某个数量。

我认为绝对没有理由使用异常处理作为代码中正常流程控制的手段。它很昂贵，很难阅读（只要看看你自己的第一个例子；我意识到它可能写得很快，但是当_map还没有初始化，你最终得到的是一个空的映射，扔掉了你试图添加的条目），并且它在代码中散布着大量无用的 try-catch 块，这些块可以很好地隐藏real问题。再次以您自己的例子为例，如果调用_map.add()是要扔一个NullPointerException因为某些原因other than _map being null？突然间，您默默地重新创建了一张空地图，而不是向其中添加条目。我确信我不必说，由于意外的状态，这可能会导致代码中完全不相关的地方出现许多错误......

Edit:需要明确的是，上面的答案是在 Java 上下文中编写的。其他语言可能（而且显然确实）在异常的实现开销方面有所不同，但其他点仍然应该成立。