try catch 仅捕获同步运行时错误（如 ReferenceError、TypeError），无法捕获异步错误；async/await 中必须 await 后置于 try 内才能捕获 Promise 拒绝；推荐用 instanceof 判断错误类型；finally 中 return 会覆盖 try/catch 的返回值。
try catch 能捕获哪些错误
同步运行时错误可以被捕获，比如 ReferenceError、TypeError、SyntaxError（仅限 eval 中）、RangeError 等。但以下情况**不会被捕获**：
try {
setTimeout(() => {
throw new Error('异步错误');
}, 0);
} catch (e) {
console.log('这里不会执行');
}因为 setTimeout 的回调在事件循环新任务中执行，已脱离 try 作用域。
async/await 中 try catch 怎么写才有效
必须把 await 表达式放在 try 块内，否则 Promise 拒绝（reject）不会触发 catch。常见错误是漏掉 await 或把整个 async 函数调用包在 try 外：
-
await fetch('/api')必须在try内，否则网络失败会变成未处理的 Promise rejection -
async function foo() { throw new Error(); }调用时写成try { foo() } catch...无效——foo()返回的是 Promise，错误在 Promise 内部，需await foo()
async function getData() {
try {
const res = await fetch('/api');
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return await res.json();
} catch (err) {
console.error('请求或解析失败:', err.message);
throw err; // 可选择重新抛出
}
}
catch 块里该不该用 instanceof 判断错误类型
应该用，尤其当需要差异化处理不同错误时。直接比对 err.name 或用 instanceof 更可靠，避免字符串匹配出错：
-
err instanceof TypeError比err.name === 'TypeError'更安全（某些环境可能篡改name） - 第三方库抛出的错误可能继承自
Error，但name不标准，instanceof仍可识别其构造函数 - 注意：跨 iframe 或模块加载场景下，
instanceof可能失效（因不同全局环境的Error构造函数不等价），此时退回到检查err.constructor.name
finally 里能修改返回值吗
可以，但只对显式 return 语句生效，且有优先级规则：
- 如果
try或catch中有return 123，而finally中也有return 456，最终返回456 - 如果
finally没有return，则保留try/catch中的返回值 - 如果
finally抛出错误，它会覆盖之前任何返回值或错误（包括catch中的throw）
function test() {
try {
return 'from try';
} catch (e) {
return 'from catch';
} finally {
return 'from finally'; // 实际返回这个
}
}
这种写法容易掩盖逻辑意图，生产代码中应避免在 finally 中使用 return。
立即学习“Java免费学习笔记（深入）”；
