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

Question

我认为人们普遍认为，作为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的弱点吗？

Answer 1

只要可以预见但无法避免，就会出现例外情况。

假设，如果您是依靠某种外部API来解析数据，并且该API提供了解析方法，但是没有任何东西可以告诉您是否可以解析给定的输入（或者解析是否成功取决于因素控件，但API不提供适当的函数调用），并且当无法解析输入时，解析方法会引发异常。

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

我绝对没有理由在代码中使用异常处理作为常规流控制的手段。它很昂贵，很难阅读（只看您自己的第一个示例；我意识到它可能写得非常快，但是当_map未初始化时，最终得到的是一个空的映射，扔掉了您正在尝试的条目进行添加），并在代码中散布了大量无用的try-
catch块，这些代码很可能掩盖了 实际
问题。再次以自己的例子，如果有什么调用_map.add()是抛出一个NullPointerException由于某种原因， 其他的
不是_map幸福null？突然，您正在静默地创建一个空的映射，而不是向其添加条目。我确定我真的不必说会由于意外状态而在代码中完全不相关的地方导致任何数量的错误…

编辑： 为了清楚起见，以上答案是在Java上下文中编写的。其他语言在例外的实现开销上可能（并且显然确实如此）有所不同，但其他观点仍然应该成立。