Java异常处理提升可维护性指南

Java异常处理需规范化：按语义分业务、系统、参数异常；各层分层捕获与响应；自定义非受检异常用于业务中断，受检异常用于必须显式处理的外部故障；Controller用@ExceptionHandler集中处理；异常消息要“说人话”并附上下文；日志记录需结构化、脱敏、不生吞；善用try-with-resources和Optional减少异常源头。

Java异常处理不是写个try-catch就完事，关键在于让异常成为可读、可定位、可响应的信号。规范化的异常使用能大幅降低排查成本，让团队协作更顺畅。

统一异常分类与分层捕获

避免所有异常都用Exception兜底。按语义明确划分：业务异常（如OrderAlreadyPaidException）、系统异常（如DatabaseConnectionException）、参数异常（如InvalidParameterException）。各层只处理本层能响应的异常——Controller层转成HTTP状态码和友好的错误提示，Service层抛出带上下文的业务异常，DAO层将JDBC异常封装为受检或非受检的领域异常。

• 自定义异常继承RuntimeException（非受检）用于业务逻辑中断，避免强制try-catch污染调用链
• 对必须显式处理的外部故障（如文件不存在、远程服务超时），用受检异常并配以清晰的throws声明
• Controller中用@ExceptionHandler集中处理，避免每个接口重复写catch

异常信息要“说人话”，附带关键上下文

不写throw new RuntimeException("error")。异常消息应说明“什么错了、在哪错的、可能为什么错”。日志中记录异常时，补全请求ID、用户ID、关键参数值等追踪线索。

• 构造异常时传入格式化字符串和变量，例如：new InsufficientBalanceException("余额不足，当前：%s，需：%s", balance, amount)
• 在日志中打印异常堆栈前，先输出结构化上下文：log.error("支付失败[orderId:{}][userId:{}]", orderId, userId, e)
• 对外返回的错误信息脱敏，不暴露类名、路径、数据库字段等敏感细节

禁止“生吞”异常和空catch块

空catch是维护黑洞。即使认为异常可忽略，也必须记录日志并说明理由，否则问题会在深夜报警时突然爆发。

• 所有catch块至少调用log.warn(..., e)或log.error(..., e)
• 不要用e.printStackTrace()——它不走日志框架，无法配置级别和输出目标
• 若真需忽略（如关闭资源时的二次异常），注释清楚原因，例如：// 忽略关闭流时的IOException，主异常已记录

善用try-with-resources和Optional减少异常源头

很多异常源于资源未释放或空指针。用现代语法从根源上压低异常发生概率，比层层catch更治本。

• 所有实现AutoCloseable的资源（文件、连接、流）必须用try-with-resources自动管理
• 方法返回可能为空的对象时，优先返回Optional，调用方用ifPresent或orElseThrow显式处理空值场景
• 参数校验前置：用Objects.requireNonNull或Validate.notNull快速失败，避免深层调用后才抛NPE

基本上就这些。异常不是bug的遮羞布，而是系统健康状况的仪表盘。写得清楚，查得明白，改得安心。