Catching Different Exception Types

同学们，我们来讲一下异常处理里一个很重要的规则：当你写了多个 catch 块的时候，它们是怎么匹配的，以及为什么顺序一定要安排好。 先说清楚一点：当 try 代码块里抛出一个异常后，系统会从上往下、按你写的顺序，一个一个检查 catch 块。只要找到第一个能匹配这个异常类型的 catch，它就立刻跑进去执行里面的代码，然后其他所有的 catch 块会被直接跳过，根本不会去看。 这就像在几条巷子里找能对得上钥匙的锁，一旦打开了某扇门，就不会再看后面的门了。 所以关键词就是：，第一个匹配的获胜，后面的全部绕开。， 那这个规则会带来什么问题？我们来看一个典型例子。假设我们写了三个 catch 块，顺序是这样的：先 catch 一个 DmlException，然后 catch 一个 SObjectException，最后 catch 一个通用的 Exception。这个顺序就是对的。为什么呢？ 我们拿两种不同的异常来推演一下。 第一种场景：如果代码里抛出了一个 SObjectException。系统开始检查第一个 catch——咦，它是 DmlException，不匹配，跳过。接着看第二个 catch，刚好是 SObjectException，匹配上了！那就立刻进入第二个 catch 块处理，然后第三个通用的 Exception 就完全不看了。也就是说，特定的 SObjectException 被专门处理掉了。 第二种场景：如果代码抛出的不是上面那两个，比如一个 NullPointerException。系统先看第一个 DmlException，不匹配；再看第二个 SObjectException，也不匹配；最后看到第三个 catch 是 Exception，它是所有异常的父类，所以什么都能接住，于是就由它来处理。这样，NullPointerException 就被通用处理给兜底了。 从这个过程你能看出来，我们把最特指的异常写在前面，把最泛化的 Exception 写在最后，就能做到：不同类型的异常，能进到专门为它准备的 catch 块里处理；而意料之外的异常呢，最后还有一个“大口袋”兜着，不会让程序崩溃。 反过来，如果你把 catch(Exception) 写在第一个，那后面的 DmlException、SObjectException 这些 catch 块永远都不会执行，因为任何异常都会被第一个通用口子给截胡了，Apex 编译器甚至会直接报错，提醒你代码不可达。所以不管从编译角度还是运行逻辑，都必须让特定异常在前，通用异常在后。 这个模式就能确保每一个异常类型都被恰当地处理：该专门处理的专门处理，该统一兜底的统一兜底。请大家在写代码的时候一定记住这个顺序原则，避免出现莫名其妙被跳过或不处理的情况。 好了，这一节就讲到这里，下次遇到 try-catch，你就知道该怎么排列 catch 块的顺序了。