我认为,作为 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 上下文中编写的。其他语言可能(而且显然确实)在异常的实现开销方面有所不同,但其他点仍然应该成立。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)