Work with Errors — Types & Lifecycle

好，各位同学，今天咱们来聊一聊LWC里的错误处理。你在开发的时候，肯定碰到过代码里出毛病的情况，别慌，咱们把错误的类型和它们的脾气搞清楚了，就能稳稳地接住它们。 LWC里，错误大概来自三个地方。 第一种是，JavaScript原生错误，，就是你自己写的JS代码里出了岔子。比如你拼错了一个变量名，就会得到一个 `ReferenceError`；或者写了一句语法不通的话，就会得到一个 `SyntaxError`。这些错误都是用标准的 `throw` 语句抛出来的，咱们用 `try-catch` 包起来就能抓住。 第二种是，LDS错误，，也就是闪电数据服务（Lightning Data Service）出错。当你用 `@wire` 连接一个数据源，比如从一个记录里拿数据，如果网络抽风了，或者记录不存在，这个错误会悄悄地藏在 wire 返回对象的 `error` 属性里。所以记得去检查这个属性。 第三种是，Apex错误，，这是后端抛给我们的。比如你调用一个Apex方法，里面做了DML操作，但验证规则不通过，就会扔过来 `DmlException`；如果是安全权限问题，会有 `SecurityException`；或者开发人员自己定义的一些异常。它们都会在LWC可调用方法的返回值里以错误形式体现。 好，现在重点来了。这些错误发生之后，它们的“旅行路线”是完全不一样的，这取决于你写的是同步代码还是异步代码。 我来给你打个比方： - ，同步错误，就像在一条直直的走廊上泼了一盆水，水会顺着走廊一路向前流，流过每一个组件，最终流到最外层的应用程序那里。如果中间没人拿拖把吸掉它（也就是你不 `catch` 它），最后浏览器就会弹出一个很明显的错误提示框，里面还带着堆栈信息，用户一定能看见。所以同步代码里的错误，用户基本都能察觉到。 - ，异步错误，就完全不一样了。它更像你把一杯水偷偷倒进了地漏里，水直接流进了下水道，地面上一滴痕迹都没有。在代码里，异步操作——比如 Promise 里的 `then/catch` 没写全，或者 wire 服务的回调里出了问题——这些错误如果没有被显式地处理，它们不会爬上组件树，也不会触发那个用户可见的弹窗，而是直接默默地跑到了，浏览器控制台，里。用户正常用页面，可能根本不知道发生了错误。 这个区别非常关键。很多同学刚上手 LWC 的时候，觉得“哎，之前那个变量写错了就弹框了，怎么这次 wire 里的断句就没动静了呢”，就是因为后者是异步的。这也就意味着，对于所有异步代码，不管是 Promise 还是 wire 的回调，你，必须亲手处理错误，，要么显示一个友好提示，要么记个日志，总之不能指望它自己蹦出来给用户看。 举个例子，假设你有一段访问服务器端数据的逻辑，不小心把 `server.targets.Value` 拼错了。如果你在同步的 `connectedCallback` 里这么写，那个不可阻挡的弹出框会直接怼到用户脸上；可你要是把它放在一个 wire 处理函数或者一个 `fetch` 的 `.then` 里面，什么弹窗都不会有，只有你自己打开控制台才能看到那个刺眼的红叉。 所以记住今天的小口诀：，同步错误自动冒泡，用户一定看得到；异步错误悄悄溜走，你得主动把它捞。， 以后写 LWC 的异步操作时，别忘了给它加一个安全网——用 `.catch` 或者检查返回的 `error`，给用户一个体面的体验。 好了，这堂课就讲到这里，大家试着去自己的组件里排查一下，看看哪些地方可能漏掉了错误处理吧。