Built-In Exceptions & Common Methods

好，咱们来看看Apex里头内置的那些异常，还有查错时常用的几个方法。你平时写代码，肯定会遇到程序跑不下去、给你抛错误的情况，这些错误其实就是异常。Apex帮我们准备了好几种内置的异常类型，每一种都对应了常见的问题场景，方便我们快速定位。 比如，`DmlException`，它是当你做数据库操作失败了才抛出来的，比如插入、更新记录时，因为验证规则没通过，或者触发器里限制住了，就会触发这个异常。 `ListException`，这个一看名字就知道跟列表有关。典型的情况就是下标越界 —— 你试图去取列表里根本不存在的位置，比如一共才三个元素，你却要拿第四个，它就会抛出来。 `NullPointerException`，这个太经典了，空引用。你对着一个null的东西调用方法或者访问属性，肯定会报这个错。 `QueryException`，跟SOQL查询有关。比较常见的情形是，你用 `SELECT` 把查询结果直接赋值给一个单条记录的变量，结果回来的却是零行，系统就不知道该给你什么，于是抛出 `QueryException`。有时候你想当然地以为至少有一行数据，可实际上它就是没有，要特别留意。 还有 `SObjectException`，这个通常发生在你试图访问SObject上根本没查询过的字段。比如你只查了Name，却在代码里去取Phone，系统就会告诉你：这个字段没被查出来，你不能直接访问。 光知道异常类型还不够，我们还得能读懂错误信息。Apex的异常对象提供了一些特别好用的方法，咱们挨个说： - `getTypeName()`，返回的是异常的类型名称，也就是刚才说的那几类，比如“System.NullPointerException”，一眼就知道什么毛病。 - `getMessage()`，返回具体的错误消息文本。这个很直观，告诉你到底哪里出了问题。 - `getLineNumber()`，返回发生异常的那行代码行号。查 bug 的时候，这个太有用了，直接把你带到事发现场。 - `getCause()`，返回内部异常对象，如果这个异常是被另一个异常包装起来的，就能通过它追溯到根因；要是没有，它就是 null。 - `getStackTraceString()`，返回完整的堆栈跟踪字符串。从最上层的调用一直显示到出错的地方，每一步调用关系都列出来了，非常适合详细了解执行路径。 你可能会在捕获异常时这么写：先用一个比较通用的 `Exception` 类型来 catch，然后根据实际抛出的更具体的异常，比如 `QueryException`，来做不同的处理。因为所有的异常都继承自 `Exception`，所以通用的 catch 块可以兜底，但如果你要针对性处理，就可以先捕获更具体的异常。 举个例子吧，假设你写了一段查询联系人的代码，你期望至少查到一个联系人，于是直接写成： ```apex Contact c = [SELECT LastName FROM Contact WHERE ...]; ``` 可惜，实际可能因为条件不满足，查出来 0 行，这时就会抛出 `QueryException`。你为了不让程序中断，可以这样写： ```apex try { Contact c = [SELECT LastName FROM Contact WHERE ...]; System.debug('联系人姓：' + c.LastName); } catch (QueryException qe) { System.debug('查询出错，未找到记录：' + qe.getMessage()); } catch (Exception e) { System.debug('发生了其他错误：' + e.getTypeName()); System.debug('堆栈：' + e.getStackTraceString()); } ``` 在这个例子里，先捕获更具体的 `QueryException`，单独处理查询行数的问题；如果抛出的是其他异常，比如空指针，就会被后面的通用 `Exception` 捕获，并且我们还能用 `getTypeName()` 和 `getStackTraceString()` 获得详细信息去排查。 这样一层层捕获，能让你的代码更稳健，也更容易调试。当生产环境出了问题，靠这些方法马上就能知道是什么异常、在哪一行、为什么会发生。 好了，关于内置异常和常用方法就先说到这儿，你可以在练习里多试试不同的场景，加深印象。