try-catch必须后接catch或finally，javascript中需用await捕获promise异常，java需声明异常类型且推荐try-with-resources，node.js中uncaughtexception仅捕获同步未捕获异常。
try-catch 怎么写才不会报语法错误
JavaScript 和 Java 的 try-catch 看似一样，但少写一个 catch 或漏掉花括号就会直接报错。最常见的是在 TypeScript 或严格模式下，try 后面没跟 catch 或 finally —— 这根本不是合法语句，会抛 SyntaxError: Unexpected token。
-
try块必须后接至少一个catch或finally，不能单独存在 - Java 要求
catch必须声明异常类型（如IOException），而 JavaScript 可以只写catch (e)，但不推荐省略参数名，否则无法访问错误细节 - TypeScript 中，
catch参数默认是unknown类型，直接访问e.message会报错，得先做类型守卫：if (e instanceof Error)
捕获不到 Promise 拒绝怎么办
写 try-catch 却没抓到 fetch 失败或 Promise.reject()，是因为 Promise 的异常不会自动冒泡进同步的 try 块。它属于异步错误，得用 .catch() 或 await 配合 try-catch。
- 错误写法：
try { fetch('/api'); } catch (e) { ... }——fetch返回 Promise，try只包裹了“发起请求”这一步，不包裹响应处理 - 正确写法：加
await，让执行停在 Promise settle 之后：try { const res = await fetch('/api'); ... } - 如果不用
await，就得链式调用：fetch('/api').catch(err => {...})，但注意这不会捕获后续.then()里的同步错误
Java 中 try-with-resources 为什么比手动 close 更安全
Java 里打开文件、数据库连接等资源，用传统 try-catch-finally 手动 close()，容易在 catch 或 finally 里再抛异常，导致原始异常被吞掉。而 try-with-resources 在语句结束时自动调用 close()，且能保留原始异常。
- 资源类必须实现
AutoCloseable接口，比如FileInputStream、Connection - 多个资源用分号隔开：
try (var in = new FileInputStream("a.txt"); var out = new FileOutputStream("b.txt")) { ... } - 如果
close()抛异常，它会被抑制（suppressed），可通过originalException.getSuppressed()查看，原始异常仍向上抛出
Node.js 里 uncaughtException 和 try-catch 是什么关系
process.on('uncaughtException') 不是 try-catch 的替代品，而是兜底机制。它只能捕获未被任何 try-catch 捕获的同步异常，对 Promise 拒绝、setTimeout 回调里的错误都无效。
- 它无法恢复进程状态，官方明确建议：记录日志后尽快退出，不要继续运行 —— 因为 JS 引擎可能已处于不一致状态
- 想捕获异步拒绝，得配
process.on('unhandledRejection')，两者要一起注册才完整 - 真正该用
try-catch的地方（比如 JSON 解析、用户输入校验），别偷懒扔给全局监听器 —— 那会让错误定位变模糊，也掩盖了本该处理的业务异常
异常处理的关键不在“全包”，而在清楚每个 try 的作用域边界——同步、异步、资源生命周期，三者稍一混淆，错误就悄悄漏过去了。
