引言：被try-catch淹没的代码
你是不是也写过这样的代码？方法里套三层try-catch，像给代码穿了三层防弹衣，结果运行起来还是漏洞百出。更惨的是，某天线上报错，你在几百行日志里翻了半天，才发现某个catch块里写了个e.printStackTrace()就完事了——这就像把炸弹扔进抽屉然后假装没事，迟早要炸。
一、先搞懂异常的"家谱"：别逮着Exception就抓
很多人写异常处理时，上来就是catch (Exception e)，这相当于医院把感冒和癌症用同一种方法治疗。Java的异常体系其实是个大家族，最顶层是Throwable，下面分两支：Error和Exception。Error是绝症（比如OutOfMemoryError），你治不了就别瞎掺和；Exception才是你该关心的，其中又分Checked Exception（编译时必须处理）和Unchecked Exception（运行时异常）。
划重点：捕获异常要像做手术一样精准，catch (NullPointerException e)永远比catch (Exception e)更值得称赞。那些上来就抓大而全异常的同学，建议去医院挂个号——看看全科医生和专科医生的区别。
二、自定义异常：给错误贴"快递标签"
当系统越来越复杂，你会发现Java自带的异常不够用了。比如"用户余额不足"这种业务场景，总不能扔个IllegalArgumentException吧？这时候自定义异常就像给错误贴了快递标签，让排查问题像分拣快递一样高效。
正确姿势是继承Exception或RuntimeException，提供几个常用构造函数：无参、带消息、带消息和cause。记住，业务异常建议用RuntimeException（非受检），这样不会强迫调用者写try-catch，毕竟不是所有错误都需要当场处理。就像快递员不会因为你不在家就把快递销毁——他会交给驿站（全局异常处理器）。
三、try-with-resources：自动关资源的"管家"
IO操作不关闭资源？等于出门不关水龙头。传统try-catch-finally里写close()，代码像裹脚布一样长，还容易因为异常嵌套导致资源泄漏。Java 7的try-with-resources就是来当管家的——只要资源实现了AutoCloseable接口，它会在你用完后自动关门。
看看这对比：以前写10行代码有5行是关流的，现在一行搞定。那些还在用finally手动close的同学，建议去体验下智能家居——科技就是要解放双手（和代码）。
四、全局异常处理：统一"售后服务"
每个接口都写try-catch？等于每个商店都单独设个售后服务台。Spring的@ControllerAdvice就是呼叫中心，所有异常统一处理。把重复的异常处理代码抽出来，让业务代码专注于业务，这才是"高内聚低耦合"的正确打开方式。
实现起来也简单：加个@RestControllerAdvice注解，写个@ExceptionHandler方法，按异常类型分类处理。比如参数校验异常返回400，业务异常返回500带自定义消息，系统异常返回500带默认提示。这样前端同学再也不用猜状态码是什么意思了——就像打客服电话，按1查订单，按2退货，清晰明了。
五、异常处理的"避坑指南"
- 别吞异常：catch块里至少要打日志，不然出了问题你都不知道尸体在哪。
- 别用异常控制流程：这就像用灭火器开啤酒——功能是有，但不是这么用的。
- 异常消息要具体："操作失败"不如"用户ID=123的订单不存在"，后者能让你少加班两小时。
- 尽早抛出，延迟捕获：异常发生时立刻抛出，直到有能力处理时再捕获。就像发现火情要第一时间报警，而不是自己先扛着。
结语：优雅的代码藏着对同事的温柔
异常处理不是技术炫技，而是代码的"安全气囊"。少写一层try-catch，多定义一个业务异常，表面上是代码风格的差异，实则是对系统稳定性的态度。下次再写异常处理时，想想那个要维护你代码的同事——他可能正在加班排查你吞掉的异常。毕竟，优雅的代码，都藏着对同事的温柔。