Java尝试捕获块
这是一个简单的问题：
您如何看待每次使用try catch的代码？
void myfunction() { try { instruction1(); } catch (ExceptionType1 e) { // some code } try { instruction2(); } catch (ExceptionType2 e) { // some code } try { instruction3(); } catch (ExceptionType3 e) { // some code } try { instruction4(); } catch (ExceptionType4 e) { // some code } // etc } 我知道这太可怕了，但我想知道这是否会降低性能。
尝试这样的事情:(我知道这不能回答你的问题，但它更清洁）
void myfunction() { try { instruction1(); instruction2(); instruction3(); instruction4(); } catch (ExceptionType1 e) { // some code } catch (ExceptionType2 e) { // some code } catch (ExceptionType3 e) { // some code } catch (ExceptionType4 e) { // some code } // etc }
它不会降低性能（当然不会明显），但确实看起来很糟糕。
记住黄金法则：可读代码通常是更快的代码。 首先生成可读代码，只有在certificate速度太慢时才更改它。
将您的try-catch块分组为原始代码的逻辑块（例如，一个用于打开流并从中读取数据，一个用于之后完成的所有处理），维护开发人员将感谢您。
您还应该考虑，如果捕获exception的第一个catch块没有突然结束（即，在正常流程中继续执行），则后续指令可能会抛出其他exception，这些指令依赖于先前成功完成的指令，这两个指令都是虚假，他们可以减慢你的代码。
不，这可能不会降低性能（但是，一如既往，您必须对其进行测试）。 当编译成字节码时，Javaexception处理程序将更改为字节码偏移范围和关联处理程序地址的表。 catch处理程序通常在代码的主线之外编译，因此不会影响“正常”的非exception执行。
有关更多信息，请参阅Java虚拟机规范， 第7.12节“抛出和处理exception” 。 本节还提供了如何将各种代码构造编译为字节码的示例。
如果抛出exception，使用过量的try-catch可能会在性能方面开始变得昂贵。 如果没有这么多的已检查exception或者让所有ExceptionTypes都扩展了一个常见的Exception基类，你会更好。 这样你就可以有一个try catch，它更容易阅读并具有更好的性能。
从这个答案可以看出，除非引发错误，否则性能最低。