`try/catch` 只能捕获 `throw` 抛出的异常，无法捕获函数直接 `return` 的 `error` 实例；若需统一处理，须手动判断返回值是否为 `error` 并显式 `throw`。
在 JavaScript 开发中（尤其是构建 NPM 包时），一个常见误区是混淆「抛出错误（throw new Error(...)）」与「返回错误对象（return new Error(...)）」的行为差异。try/catch 语句的设计目标是拦截运行时异常（即被 throw 中断执行流的错误），而非处理普通函数返回值——无论该返回值是否为 Error 类型实例。
例如，以下代码能被正常捕获，因为 throw 主动触发了异常流程：
let throwError = () => { throw new Error("I didn't break out!"); };
try {
let res = throwError();
} catch (err) {
console.log(err.message); // ✅ 输出：I didn't break out!
}而下面这段代码不会进入 catch 块，因为 returnError() 仅返回一个 Error 对象，未中断执行流，try 块内无异常发生：
let returnError = () => new Error("I broke out!");
try {
let res = returnError(); // ❌ 此行不抛错，res = Error instance
console.log('This still runs!');
} catch (err) {
console.log('This never executes');
}
// → 控制台输出：This still runs!⚠️ 注意：此时错误并未“逃逸”，而是被静默赋值给了 res —— 真正的“破出”往往源于后续对 res 的误用（如试图调用 res.json() 或解构不存在属性），这才引发实际报错，但那已不在原始 try 范围内。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
✅ 正确做法：若设计 API 允许函数返回 Error 实例作为错误信号（常见于某些回调风格或同步校验逻辑），则必须在 try 块中主动检测并转换：
let result;
const returnError = () => new Error("I broke out!");
try {
const res = returnError();
// 显式检查并重抛，使 try/catch 生效
if (res instanceof Error) {
throw res;
}
result = res;
} catch (err) {
result = {
message: err.message,
name: err.name,
stack: err.stack // 可选：保留调试信息
};
}
console.log(result);
// → { name: "Error", message: "I broke out!", stack: "..." }? 最佳实践建议：
- 明确契约：API 文档应清晰说明函数是 throw 错误还是 return 错误，避免混合使用；
- 优先 throw：对于同步阻塞性错误（如参数校验失败），推荐直接 throw，语义更清晰、try/catch 开箱即用；
- 避免 return Error：除非刻意实现“错误即值（error-as-value）”模式（如某些函数式库），否则易引发上述误解；
- 类型守卫增强：在 TypeScript 中可配合类型谓词（type predicate）提升安全性，例如 isError(err: unknown): err is Error。
归根结底，try/catch 不是万能的错误过滤器——它是异常控制流机制，而非值处理工具。理解其作用边界，才能写出健壮、可维护的 JavaScript 错误处理逻辑。
