Exceptions — Overview & What Happens

同学们，今天我们来看一下在Apex中如何用 throw 和 try-catch-finally 来优雅地处理错误。Slide上写的“使用throw生成Inbox”，这里可能有个小笔误——throw 是用来抛出异常的，也就是说，当我们发现一个错误情况，就“扔”出一个异常对象，而不是生成收件箱。大家知道这个意思就好。 好的，我们先说 throw 和 try-catch-finally 这套机制。你把可能出错的代码放在 try 块里，如果运行中真的出了问题，代码可以用 throw 抛出一个异常；紧接着，catch 块会抓住这个异常，你就可以在 catch 里记录日志或者给用户一个友好的提示。不管有没有异常，finally 块里的代码最后一定会执行，通常用来做清理工作，比如关闭文件流或者释放资源。 这套机制最大的优点就是异常会在调用堆栈中自动冒泡。什么意思呢？比如方法A调用方法B，方法B又调用方法C，如果C里抛出了一个异常，而C自己没有 try-catch 去捕获它，这个异常就会自动向上一层B传递；B如果也没捕获，就继续传给A。一直传到某层有 catch 把它接住，或者直接变成未处理异常。这样我们就不需要在每一个方法里都写一大堆错误检查代码，错误处理逻辑可以集中在一个地方，代码会干净很多。 当异常发生的时候，代码会立即暂停执行，当前事务的所有DML操作——也就是对数据库的修改——会自动回滚，这就像是“后悔药”，不会让出错的事务留下一堆半截子的脏数据。同时系统还会把这个异常记录下来，方便我们排查。 那如果异常一直没被捕获，变成了未处理异常呢？系统会做两件事：第一，给最后修改这段代码的开发人员发送一封通知邮件；第二，在用户界面上弹出一条错误提示。谁是这个开发人员呢？就是那个“Last ModifiedBy”，通常是最后一次保存类的同学。当然，这个邮件通知是可以配置的，你可以在Salesforce设置菜单里找到“Apex异常电子邮件”，或者通过工具API来添加自己要接收邮件的邮箱。 这里有个很贴心的设计：重复的异常会抑制后续邮件。也就是说，同一个错误如果在短时间内反复出现，系统只会发一次邮件，不会用海量邮件轰炸你的收件箱。不过要注意，每个应用服务器每小时最多只发10封异常邮件，所以不能全靠邮件来监控。 还有两个重要场景是不会发邮件的：一个是匿名Apex执行，也就是你在开发者控制台里随手运行的那几行代码；另一个是标了 @AuraEnabled 的Aura组件方法（Slide里写的是 @Aura Essentials，大家理解成Lightning组件的方法就行）。是因为这些场景下调用方形形色色，系统不知道把邮件发给谁才合适。 最后老师再多叮嘱一句：虽然配置了邮件通知很方便，但因为每小时有10封的限制，而且可能被重复异常抑制，我们不能只依赖邮件来发现问题。更科学的方式是借助事件监控（Event Monitoring）来跟踪异常，这样可以看到全量、实时的异常数据，帮助我们在系统出问题的时候快速定位，而不用担心漏掉关键信息。 好，关于异常处理的核心点就讲完了。简单回顾一下：用 throw 抛出异常，用 try-catch-finally 捕获处理，异常会自动冒泡，事务自动回滚并记录日志，未处理的会发邮件给最后修改者、同时提示用户，重复异常会抑制邮件，匿名执行和Aura方法不发邮件，每小时限10封，最好再配合事件监控一起用。大家课后可以自己写个小例子跑一跑，感受下异常冒泡的过程。有什么不清楚的，随时来问老师。