别再只会写 try-catch 敷衍编译器了！带你彻底搞懂如何正确处理异常信息

目录一、什么时候该 try-catch？（悄悄接住，优雅降级）二、什么时候该抛出异常？（核心阻断，快速失败）三、异常处理的“黑洞”与正确原理1. 生吞异常（Catch块留空）2. 只打印 e.getMessage()3. 滥用 e.printStackTrace()正确姿势：使用日志框架并保留 Root Cause四、总结在 Java 开发中，异常处理（Exception Handling）是一项至关重要却又极易被误用的基本功。很多新人在面对异常时常常陷入迷茫：要么分不清何时该使用try-catch捕获、何时该直接向外抛出（throw）；要么为了图省事，在catch块中什么也不写，硬生生地将异常“吞没”。这两种做法不仅违背了编程规范，更会给线上的问题排查埋下巨大隐患。那么，在实际开发中，到底什么场景下应该抛出异常？什么场景下应该捕获异常？捕获之后又该如何规范、优雅地处理呢？一、什么时候该 try-catch？（悄悄接住，优雅降级）很多新人会把try-catch当成兜底的万能药，其实它的核心应用场景之一是：隐藏异常，不让调用者感知异常，并做降级处理。也就是说，当你不想让一次异常中断整个流程、导致后续代码无法运行时，就用 try-catch 把它拦下来。更进一步，把它当成异常场景下的“降级开关”。就比如说，拙野在开发一个电商首页，页面有核心的商品数据，也有非核心的“推荐数据”（来自一个不太稳定的外部服务）。如果推荐服务挂了，我们显然不应该让整个页面都报错崩溃。代码语言描述这个过程如下：@Service @Slf4j public class ProductService { public PageResult getHomePageData() { PageResult result = new PageResult(); // 1. 获取核心数据（不能try-catch，报错直接抛给前端提示系统异常） result.setMainData(getCoreData()); // 2. 获取非核心推荐数据（可能超时报错，需要降级） try { result.setRecommendData(callRecommendService()); } catch (Exception e) { // 一旦出事，立刻捕获，记录日志留底排查 log.warn("获取推荐数据失败，降级为空列表", e); // 返回默认值或空列表，不阻断核心流程 result.setRecommendData(Collections.emptyList()); } return result; } }这就是try-catch的用武之地：自己把自己关在屋子里，外部服务想怎么抛异常就怎么抛，它不受别人影响，也不影响核心主干业务。让用户依旧能看到页面，业务流程继续走下去。