Update 69. 只针对异常的情况下才使用异常.md

This commit is contained in:
Joe 2019-03-05 13:57:53 +08:00 committed by GitHub
parent 7d5f09370b
commit 86f996b04c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -27,7 +27,7 @@ for ( Mountain m : range )
  实际上基于异常的模式比标准模式要慢得多。在我本地的机器上,对于一个有 100 个元素的数组进行遍历,标准模式比基于异常的模式快了 2 倍。
  基于异常的循环模式不仅模糊了代码的意图,讲起了它的性能,而且它还不能保证正常工作!如果出现了不相关的 bug这个模式会悄悄的消失从而掩盖了这个 Bug极大地增加了调试过程的复杂性。假设循环体的计算过程中调用了一个方法这个方法执行了对某个不相关数组的越界访问。如果使用合理的循环模式这个 Bug 会产生未被捕捉的异常,从而导致线程立即结束,并产生完整的堆栈轨迹。如果使用这个被误导的基于异常的循环模式,与这个 Bug 相关的异常将会被捕捉到,并且被错误的解释为正常的循环终止条件。
  基于异常的循环模式不仅模糊了代码的意图,降低了它的性能,而且它还不能保证正常工作!如果出现了不相关的 bug这个模式会悄悄的消失从而掩盖了这个 Bug极大地增加了调试过程的复杂性。假设循环体的计算过程中调用了一个方法这个方法执行了对某个不相关数组的越界访问。如果使用合理的循环模式这个 Bug 会产生未被捕捉的异常,从而导致线程立即结束,并产生完整的堆栈轨迹。如果使用这个被误导的基于异常的循环模式,与这个 Bug 相关的异常将会被捕捉到,并且被错误的解释为正常的循环终止条件。
  这个例子的教训很简单:顾名思义,**异常应该只用于异常的情况下;他们永远不应该用于正常的程序控制流程。** 一般的,应该优先使用标准的、容易理解的模式,而不是那些声称可以提供更好性能的、弄巧成拙的方法。即使真的能够改进性能,面对平台的不断改进,这种模型的性能优势也不可能一直保持。然而这种过度聪明的模式带来的微妙 Bug 和维护的痛苦将依旧存在。