Handle Errors from Apex

好，同学们，今天我们来聊聊Apex错误处理，就是当你的服务器端代码出问题的时候，怎么把合适的消息传到给用户界面，既方便调试又不会泄露敏感信息。 首先你记住，如果Apex里抛出异常但你没有主动处理，系统默认返回的东西是很详细的——完整的堆栈跟踪，类名、行号全都有。这在开发调试阶段确实很管用，一看出错位置马上就能定位。但万一这种信息跑到生产环境的用户面前，可就糟糕了，等于是把代码内部结构曝光了，不安全。 所以Salesforce给我们一个专门的类叫AuraHandledException。用它把异常包一下扔出去，客户端收到的就只有一段干净的、给用户看的消息，完全没有堆栈跟踪。这就很适合直接展示在页面上。 如果你需要自己定义一些业务上的异常类型，比如余额不足之类，你可以让你的自定义异常继承自Exception类。这样你抛出的异常既有你自己的类型，也保留了完整的堆栈跟踪——方便日志里查看，但在返回给客户端之前，还是建议包装成用户友好的消息。 还有个处理空指针的好工具，就是安全导航操作符，一个问号一个点。当你访问一个可能为null的对象属性时，用`?.`，如果它是null，就直接返回null，不会抛出让人头疼的空指针异常。 到了稍微复杂一点的项目，团队里可以约定一套标准的错误响应格式。怎么做呢？自己写一个错误包装器类，里面可以定义像severity严重程度、errorMessage错误消息等等这样的属性。这样无论哪个开发人员写接口，返回的错误结构都是一致的，前端处理起来也方便。 最后，最佳实践是：针对不同的异常类型，使用多个try-catch块分别处理。比如你可以有针对远程调用的异常、DML操作的异常、通用的异常。只捕获你预料中的错误，处理好，然后把剩下的异常传出去，让更外层的逻辑统一兜底。还有，把你的业务代码按错误处理场景拆分成不同模块，这样职责更清晰。 如果你需要实际代码参考，去GitHub上搜lwc-recipes，这个仓库里有大量Apex错误处理的示例，直接拿来看就懂了。 好了，关于Apex错误处理的要点就讲这么多，大家理解了吗？下次课我们继续。