异常处理机制不改变功能但影响结构清晰度与可维护性：合理使用可分离正常与错误逻辑、提升语义表达、强化资源管理；滥用则导致职责不清、语义模糊、结构割裂。
异常处理机制本身不改变代码功能，但会显著影响代码结构的清晰度与可维护性。用得好，业务逻辑干净利落；用得乱，主流程被切割得支离破碎。
异常处理让正常逻辑和错误逻辑自然分离
没有异常机制时，开发者常靠返回码、null值或布尔标志判断操作是否成功，大量if-else嵌套在主流程中，比如：
不推荐写法：
if (file != null) {
if (file.exists()) {
if (file.canRead()) {
// 实际读取逻辑
} else { /* 权限错误 */ }
} else { /* 文件不存在 */ }
} else { /* 空指针 */ }
立即学习“Java免费学习笔记（深入）”；
引入try-catch后，主路径回归线性表达：
try (FileInputStream fis = new FileInputStream(path)) {
byte[] data = fis.readAllBytes();
process(data);
} catch (FileNotFoundException e) {
logger.warn("配置文件缺失，使用默认值");
} catch (SecurityException e) {
throw new AppConfigurationException("无读取权限", e);
}
这种分离使阅读者一眼抓住“做什么”，再按需查看“出错了怎么办”。
过度捕获会割裂业务语义
把整段服务方法包进一个大try块，或对每个工具调用都单独加try-catch，都会模糊职责边界：
- 一个方法本该只做“解析JSON并入库”，却因同时处理文件打开、解析失败、数据库连接异常而变得职责不清
- 多个相似catch块重复出现（如每个DAO方法都自己log+rethrow），说明错误处理策略未统一抽象
- 捕获Exception或Throwable而不区分类型，掩盖了问题本质，也阻碍了针对性恢复策略
建议按层级收敛异常处理：底层模块抛出明确异常（如DataAccessException），中间层做转换与补充上下文，顶层统一兜底并反馈用户。
资源管理强化结构一致性
finally或try-with-resources不是锦上添花，而是强制结构规范的手段：
- 手动close写在finally里，确保无论是否异常，流、连接、锁都被释放
- try-with-resources自动调用close()，语法上就把资源生命周期绑定到代码块作用域内
- 资源声明位置即表明其作用范围，比散落在各处的open/close更易追踪
例如使用BufferedReader时，用try-with-resources可省去finally里的判空和关闭逻辑，结构更紧凑、不易遗漏。
自定义异常提升语义表达力
抛出IllegalArgumentException或NullPointerException，只告诉别人“参数错了”或“对象为空”；而抛出UserNotActivatedException或InsufficientBalanceException，则直接传达业务含义：
- 调用方无需解析错误消息字符串，就能理解失败原因
- 前端可根据异常类型决定跳转页面、弹窗提示或静默重试
- 日志系统可基于异常类名做分类聚合，便于监控告警
这类异常不增加运行开销，却让代码结构承载更多设计意图，从“怎么跑”升级为“为什么这么跑”。
