在JavaScript中，throw是一条控制流语句，它的作用是从当前执行位置主动抛出一个异常，迫使引擎停止正常的顺序执行，并沿着调用栈向上寻找可以处理该异常的代码。与自动由运行时产生的错误不同，throw允许开发者根据业务逻辑自行决定何时中断程序，比如参数校验失败、网络请求返回非预期结构、或者某个必需资源缺失。理解throw的工作方式，是写出可维护、易调试代码的基础。
throw语句的基本语法
throw语句的语法非常简单，后面跟一个表达式，这个表达式的值就是被抛出的“错误值”。当引擎执行到throw时，会先计算表达式，然后立即中断当前函数的执行，并将这个值作为异常抛出。语法形式如下：
// 抛出字符串
throw '参数不能为空';
// 抛出数字
throw 404;
// 抛出Error对象
throw new Error('发生了一个错误');
// 抛出自定义错误
class ValidationError extends Error {
constructor(message) {
super(message);
this.name = 'ValidationError';
}
}
throw new ValidationError('邮箱格式不正确');
从上面可以看出，JavaScript并没有限制throw后面必须是Error对象。任何类型的值，包括原始类型、普通对象、函数，都可以被抛出。但是，如果抛出的是非Error类型，在捕获时就会丢失堆栈信息和标准错误属性，给排查问题带来困难。
因此，尽管语法上允许，工程实践中通常建议只抛出Error及其子类的实例。Error对象自带message、stack等属性，现代运行时会自动捕获抛出位置的调用堆栈，方便在日志中定位问题。如果业务需要区分错误种类，应通过继承Error来创建自定义错误类，而不是用字符串或普通对象凑合。
如何在不同场景中抛出错误
最常见的用法是在函数开头进行参数校验，当传入值不满足约束时立即抛出，避免错误状态向下游传播。这种“快速失败”的策略能让bug更早暴露。下面展示一个带校验的工具函数：
function divide(a, b) {
if (typeof a !== 'number' || typeof b !== 'number') {
throw new TypeError('a和b必须为数字');
}
if (b === 0) {
throw new RangeError('除数不能为0');
}
return a / b;
}
try {
console.log(divide(10, 0));
} catch (err) {
console.error(err.name + ': ' + err.message);
}
在同步代码中，throw会与try-catch自然配合。但在异步回调或Promise中，情况略有不同。如果在Promise执行器函数内部throw，相当于调用reject；而在async函数内部throw，会使该函数返回的Promise变为rejected状态。开发者需要清楚不同异步模型下错误的传递路径。
例如，在基于回调的代码中直接throw并不会被外部的try-catch捕获，因为回调可能在另一个事件循环 tick 中执行。此时应通过回调的第一个参数传递错误，或改用Promise/async-await结构。在async函数里，throw就是返回拒绝态的语法糖，外部可用try-catch或catch方法统一处理，这让异步错误处理和同步代码风格保持一致。
throw与错误捕获的配合机制
当throw被执行后，引擎会从当前作用域开始向外层作用域查找最近的try语句。如果找到对应的catch块，就将抛出的错误对象作为参数传入，并恢复执行流；如果一直找到全局作用域仍未捕获，对于浏览器环境会在控制台输出未处理异常，Node.js环境下则可能使进程退出（取决于版本和配置）。
function level3() {
throw new Error('第三层出错');
}
function level2() {
level3();
}
function level1() {
try {
level2();
} catch (e) {
console.log('在level1捕获：' + e.message);
}
}
level1();
上面的调用链说明，即使throw发生在深层函数，只要某一级调用方用try包裹了调用，就能拦截错误。这种机制让我们可以在合适的边界统一处理异常，比如在处理HTTP请求的控制器外层捕获业务错误并返回500响应，而不需要在每个底层函数里写繁琐的判断。
需要注意的是，catch捕获到的是throw表达式求值后的结果。如果抛出的是自定义错误，可以通过判断err.name或instanceof来分流处理。另外，ES2019引入了可选的finally块，无论是否抛出错误都会执行，适合用来释放文件句柄、关闭数据库连接等清理工作，和throw形成完整的资源安全管理闭环。
常见误区与最佳实践
一个常见误区是认为throw只能用于“真正的bug”。实际上，throw也是正常的流程控制补充手段，用于表达“这里无法继续按预期执行”的语义。另一个误区是在库代码中吞掉错误或不抛具体信息，导致调用方无法诊断。好的做法是抛出带有清晰message和恰当类型的错误，并在文档中说明可能抛出的错误种类。
| 做法 | 说明 | 推荐度 |
|---|---|---|
| 抛出字符串 | 简单但无堆栈，难维护 | 低 |
| 抛出Error实例 | 有message和stack，通用 | 高 |
| 抛出自定义错误类 | 便于按类型捕获和处理 | 高 |
在团队项目中，建议统一定义业务错误基类，例如BusinessError，再派生出具体的校验错误、权限错误等。这样在全局错误中间件中就能通过类型快速区分用户错误和系统错误，返回不同的响应码和提示，而不是把所有异常都当成服务器故障。
最后，throw虽好，但不应替代正常的返回值逻辑。对于可预期的业务分支，用返回值或Promise resolve表达更清晰；只有当执行无法继续、属于“异常”时才使用throw。合理运用throw与try-catch，才能让JavaScript应用在复杂逻辑下依然稳健。
JavaScriptthrow_statementerror_handling修改时间：2026-08-01 22:54:29