javascript异常处理核心是try-catch-finally：try包裹可能出错逻辑，catch捕获并分类响应error实例，throw主动抛出业务异常，finally确保清理代码必执行；不可替代条件判断或静默吞错。
JavaScript 流程控制中处理异常分支，核心不是靠 if 或 switch 去“判断错误”，而是用专门的异常处理结构——try-catch-finally 主动捕获并响应运行时意外。
用 try-catch 捕获可预见的运行时异常
当某段代码可能因外部输入、资源缺失或逻辑边界问题抛出错误（如访问 undefined 属性、网络请求失败、JSON 解析出错），应将其包裹在 try 块中。一旦发生异常，JS 引擎立即中断当前执行，跳转至匹配的 catch 块：
-
try块里只放可能出错的业务逻辑，避免塞入无关代码 -
catch参数（如error）是 Error 实例，可读取error.message、error.name进行分类响应 - 不要用
catch处理本该由条件判断解决的问题（例如用if (obj)检查空值，而非等它报TypeError再 catch）
用 throw 主动制造业务异常分支
当程序检测到非法状态但 JS 不会自动报错时，需手动抛出异常，把控制权交给上层异常处理流程：
- 函数内部验证参数：如
if (age - 构造带语义的错误对象：用
new TypeError()、new RangeError()等子类，便于后续精准捕获 - throw 后的代码不再执行，相当于一次强制的“异常跳转”，形成明确的失败分支
用 finally 保证清理逻辑必执行
无论 try 中是否出错、catch 是否触发，finally 块中的代码总会运行。适合释放资源、重置状态、关闭加载提示等收尾工作：
- 常见于异步操作后：打开 loading → try 请求 → catch 处理失败 → finally 关闭 loading
- 避免在 try/catch 中重复写清理代码，统一收口更可靠
- 即使
catch里又 throw 新错误，finally仍会先执行
避免把异常处理写成条件分支的替代品
异常分支 ≠ 错误条件判断。以下做法应避免：
- 不用
try-catch替代if (data && data.items)这类基础存在性检查 - 不把用户输入校验（如邮箱格式）全扔进 try，而应先用正则或工具函数预判
- 不滥用
catch{}（空 catch），它会静默吞掉错误，导致调试困难
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
