深夜两点线上告警群突然炸了。订单服务超时率飙升StackOverflow的堆栈信息刷了满屏——不是递归溢出是同一个异常在调用链里被反复包装了十几层每一层都追加一段“上下文”最终打印出来时光是caused by就占了三个屏幕。有人花了二十分钟才定位到根因最后发现只是下游一个字段为空而那个NullPointerException在最底层被try-catch吞掉换成了一个“业务异常”扔了出来。这样的场景在团队Java项目里并不罕见。异常处理这件事看着每个程序员都会但一旦变成团队协作就迅速沦为灾难现场有人习惯性地catch(Exception e)然后e.printStackTrace()有人把业务错误全包装成RuntimeException抛给前端还有人对检查型异常深恶痛绝遇到编译不通过就直接把异常类型换成Exception。当维护者需要从一个“看似友好”的异常中反向追溯业务逻辑时这个系统的可维护性已经亮起了红灯。异常处理的第一性原理不是“捕获”而是“契约”。异常本身就是方法签名的一部分它承诺了“什么情况下这个调用会失败失败后调用方需要如何应对”。一个规范的异常体系就是一套清晰的业务边界和错误协商机制。团队里如果每个人理解不同那异常处理就只是给代码增加了噪音而不是价值。选对异常类型比写十个注释都管用。Java里检查型异常和非检查型异常的分界一直是争论不休的话题。但从维护角度看核心原则很简单调用方能否合理地从中恢复能恢复就用检查型异常逼他处理不能恢复就用非检查型异常让他尽早崩溃。比如参数校验失败、文件不存在、数据库连接断开这些属于外部条件调用方往往可以给出替代方案——抛IOException或自定义CheckedException都说得过去。而空指针、数组越界、不合法的状态这些属于程序内部bug再怎么强制捕获也恢复不了直接让它弹到全局处理器反而更快暴露问题。可惜的是很多团队把这条线完全画混了。Service层里一个findById方法数据库查不到记录居然抛了一个RuntimeExceptionController层为了不返回500又把所有异常都塞进一个Result里返回code500。结果是业务逻辑的错误码体系与Java异常体系完全脱节维护者需要在两个世界里来回翻译一旦翻译失误就是上线事故。自定义异常不是装饰品它是业务语义的浓缩。团队项目里最常见的乱象之一就是直接抛出new RuntimeException(订单不存在)。这种异常没有任何类型区分调用方只能靠解析字符串来识别错误脆弱得不堪一击。一个规范的团队应该为每个核心业务域定义清晰的异常类型比如OrderNotFoundException、PaymentTimeoutException、StockInsufficientException让异常类名本身就成为文档。异常类名就是错误码别把错误码藏进message里——否则当你要针对某类异常做重试、降级或监控时只能通过contains判断又慢又易错。但自定义异常也不是越多越好。设计异常类型时要考虑团队的实际使用场景如果你只是需要一个错误码给前端展示那么一个BusinessException带code字段比几十个专门异常类更易维护。异常类型的粒度要匹配“处理的单元”如果失败后每个调用方都只能统一catch(Exception)那你定义了十个类也白搭反而增加了匹配成本。好的做法是顶层有一个通用基础异常如BaseException下面按业务域扩展关键错误单独成类普通错误复用基础异常加错误码。异常信息不是写给自己看的是写给未来的维护者看的。一个“订单不存在”的message在日志里毫无检索价值——是哪个订单哪个用户在哪个操作中触发的规范的做法是把关键业务标识拼进message里比如“订单[id12345]不存在用户[id67890]在提交支付时触发”。同时message里禁止拼接未经脱敏的敏感信息比如密码、身份证号、完整邮箱否则日志审计就是一场噩梦。团队应该约定统一的message模板甚至通过自定义异常类时强制传参来保证。这里有个很容易被忽略的点异常信息要区分“给人看的”和“给机器看的”。给前端展示的message措辞要友好不能把堆栈直接怼到用户脸上但写入日志的message则需要包含足够的上下文。很多时候这两个需求是冲突的——同样的message既想优雅又想详细就会变成四不像。成熟的方案是异常自带两个信息用户提示信息userMessage和日志上下文context字段全局处理器分别取用。但也不必过度设计至少得想清楚这条异常未来会在哪几个地方出现谁来看看到后要做什么。吞异常是维护性的头号杀手。catch块里什么也不写或者只写一句“ignore”等于在代码里埋地雷。线上常见的诡异bug——明明报了错日志里却干干净净数据就断了——十有八九是这种空catch导致的。如果你不打算处理这个异常就不要catch它如果你catch了它就必须给出一个合理的出路要么记录日志要么重新抛出一个更有上下文的新异常要么做补偿回滚。哪怕你确实想忽略某个特定异常也必须在注释里写明“为什么可以忽略”以及“忽略后的后果”。否则三个月后别人看到空catch只会一脸茫然地选择把它删掉然后引入新的bug。保留cause链是对异常最基本的尊重。很多程序员在包装异常时喜欢图省事直接throw new BusinessException(处理失败)完全把原来的异常对象丢掉。这么做等于毁掉了唯一的诊断线索。真正有用的包装是这样的throw new BusinessException(扣款失败原因 e.getMessage(), e)。把原因传给新异常的构造器让它成为cause。这样即使嵌套了五六层维护者依然能通过完整的堆栈和cause链条追溯到最原始的根因。Java标准库和Spring都保留了这个能力一个合格的团队应当把“禁止丢失cause”写进代码评审的检查清单。不过也要小心另一种极端无节制地包装异常。每层都catch再throw最终堆栈里全是重复信息。更好的实践是能直接传播的异常就不包装只有跨了模块边界或者需要补充语义时才包装。比如基础设施层的SQLException传到Service层时可以包装成DataAccessException并补上操作的具体方法但Service层到Controller层如果Controller不需要特殊处理那就直接放行。过多的包装不仅让日志尿崩还增加了运行时栈深度。分层的边界决定了异常应该在哪里转换。团队项目里最常见的是Controller、Service、Repository三层结构。Repository层抛出的异常偏技术比如“无法连接数据库”“唯一索引冲突”Service层是业务核心应该负责把底层异常转换为业务异常Controller层则尽量减少异常处理逻辑尽量交给全局处理器。如果这个边界没划清就会出现技术异常窜到Controller甚至前端或者业务异常被底层捕获后错误降级——这两种情况都在增加维护成本。一个实用的约定是Repository层只抛数据访问异常Service层只抛业务异常Controller层不catch任何异常除非要做文件上传等特殊处理。同时跨模块调用比如通过HTTP调用另一个服务时要在网关层或SDK层统一处理响应与异常之间的转换让服务内部始终面对的是异常而不是错误码。这样整个调用链上每个异常都有明确的主人每个层次只关心自己该关心的事情。全局异常处理器不是用来偷懒的而是兜底的。Spring Boot中一个精心设计的RestControllerAdvice可以统一处理所有未捕获异常把技术异常转换成友好的响应把业务异常映射到对应的HTTP状态码。但很多团队把全局处理器当成了“万能垃圾场”Service层所有方法都只抛RuntimeException所有错误都靠处理器返回一个code错误类型完全依赖枚举。最终导致业务判断逻辑全部堆在处理器里和Controller、Service的代码脱节。理想的状态是全局处理器只处理“异常边界”上的通用逻辑比如记录未预期异常的日志、统一封装响应格式、转换认证失败等通用异常。业务性的分支判断应该发生在Service的内部——如果你为了“如果订单状态是已取消就返回错误如果库存不足就返回另一个错误”而把这两个条件都写成异常抛给处理器那说明你该在一个方法里用if-else判断而不是用异常流控制。记住异常不能替代正常流程的判断别把业务控制流建立在异常上。资源清理的命运不该拴在finally上。Java 7之后try-with-resources已经足够好用但很多老项目还是习惯在finally里close而且close方法本身的异常还处理不对。资源泄漏很难被测试发现往往在高峰期宕机时才暴露。凡是实现了AutoCloseable的资源一律用try-with-resources声明。这不仅让代码更整洁还保证关闭顺序和异常的优先级都由JVM管理不会出现“关闭失败覆盖原始异常”的坑。但也要注意try-with-resources不是万能钥匙。有些资源比如HTTP连接池里的连接关闭时实际上是归还而不是真正销毁此时就不能盲目在finally里close而是交给框架管理。团队里需要明确两份清单哪些资源必须手动关闭文件流、网络流、JDBC连接哪些资源交给容器管理Spring管理的Bean。关闭资源的责任一定要落到就近编码的人身上否则就会沦为你关了它却没关好、别人又去重关的角逐。日志和异常是一对搭档但别把它们混为一谈。异常本身自带堆栈不需要你专门打印堆栈后再抛出——如果catch了异常后又log.error(e)再throw new Exception(e)会导致同一段错误在日志里出现两遍并且第一遍没有业务上下文。正确的方式是要么在catch中记录有上下文的日志然后处理掉要么不记录直接包装抛出让最终捕获它的全局处理器或最外层统一记录。如果非要两者都做那么在抛出时不要log否则就是重复。另一个常见误区是日志级别。业务异常如“用户未登录”其实属于正常输入反馈不该用error级别刷屏而技术异常如数据库连接失败才需要error。一条实用的规范判断这个异常是否属于“预期内”的流程分支预期内用warn或info预期外用error。这能极大减少告警噪音让维护者只关注真正要处理的问题。假如所有异常都打error那Error级别的告警就失去了意义真出事时反而没人看。规范要落地光靠文档没戏得靠工具和评审。团队可以约定一套自定义异常的基类模板用IDE的代码模板或项目骨架一键生成可以在代码仓库里维护一个异常码注册表避免重复编号可以在CI里接入Checkstyle或SpotBugs把“printStackTrace”“空catch”“忽略异常”等模式直接编译失败。自动检查只能挡住低级错误更深层的规范要靠代码评审的氛围。评审时对异常处理的审查应该有一个固定套路看到catch先问“这个catch的目的是什么有没有更好的出路”看到throw先问“这个异常的类型是否准确message里有没有关键上下文cause丢了没”看到方法签名先问“这个异常是否应该被声明调用方会怎么处理它”这些问题看似简单但团队如果能持续追问不出三个迭代代码质量就能拉开一个身位。最容易被忽视的是异常处理的“一致性”。代码库里同时存在三种风格有人抛BusinessException有人返回Result对象有人直接让NullPointerException裸奔。维护者看到每一种都要重新调整心智模型改一个bug要来回切换好几套思路。所以真正的规范不在于每个异常都处理得多么精美而在于整个团队对“什么情况抛异常、什么情况返回错误、什么情况吞掉”达成相同的默契。一致性比绝对正确更重要因为维护成本往往取决于代码读起来是否“平平无奇”。回到文章开头的那个深夜。如果当时那个团队有这些约定异常类型语义清晰message包含了订单号包装时不丢causeLog只记录一次日志级别设置合理——那么定位问题的时间可以从二十分钟压缩到两分钟。规范的异常处理不是给代码添彩而是给未来的自己和管理者留一条退路。毕竟生产环境不会给你重来的机会但良好的异常处理能让你在事故发生时少掉一半头发。