处理线上问题时我最怕看到这样的代码catch (Exception e) {}——一个空catch块像一个沉默的嫌疑人异常被接住了但什么也没做问题就像沉入深海。这就是我今天想聊的try-catch使用。try-catch几乎是所有编程语言里最基础的语法之一但它绝不是把可能出错的代码包起来这么简单。很多人写了几年代码依然会在异常处理上栽跟头。这篇文章我想从底层执行逻辑、工程化写法、常见陷阱到异常设计把try-catch这件事一次说透。不管是刚入门的新人还是有几年经验的开发者应该都能从中找到一些值得回味的细节。1. 先从一次线上事故说起try-catch到底在保护什么1.1 没有try-catch时一次异常会发生什么去年我们团队出过一个事故一个定时报表任务每天晚上聚合全量数据跑完大概要四十分钟。某天凌晨数据源里混入一条格式异常的记录解析到那一行时抛了个NumberFormatException整个任务直接中断日志里留下一大段堆栈信息然后线程死了。第二天业务方发现报表没生成问了一圈最后查日志才定位到是那条脏数据。这个问题更让人头疼的不是异常本身而是它造成的连锁反应任务中断后没有重试机制也没人收到报警数据链路整段缺失。假如当时代码里用了try-catch把单条解析失败这个错误隔离出来记录失败原因后跳过后续的数据仍然能正常处理事故就只是一条warning日志的事。这个例子说明了一个核心事实try-catch的第一层价值是隔离故障。它不是让错误不发生而是让错误的影响面积可控。程序运行过程中IO异常、格式异常、网络超时、空指针这些运行时错误永远不可能靠代码审查全部消灭。如果没有try-catch任何一个微小的异常都有可能引爆整个进程让服务直接宕机。1.2 try-catch真正解决的三个问题很多人对try-catch的理解停留在防止程序崩溃上这个理解没错但太片面。按我自己的工程经验try-catch实际解决了三个层次的问题保证程序不因为局部错误整体终止这是最底层的保护。某个操作失败至少不能让整个服务挂掉这是生产环境最基本的底线。提供稳定的反馈路径用户的请求因为参数问题抛异常如果直接让页面变成500空页面体验很差。通过catch捕获后你可以给用户返回一个友好的错误提示或者返回一个默认值这是降级反馈。保留足够的诊断上下文异常对象本身携带了堆栈信息能告诉开发人员哪里出了问题。配合日志采集你可以通过一条error日志快速定位到具体代码行。如果连catch都没有你连定位问题的入口都找不到。三个层次对应的是稳定性、可交互性和可排查性。你写try-catch时应该时刻问自己这一层保护解决的是这三个问题里的哪一个如果一个问题都不解决那这个try-catch大概率是多余的甚至是隐患。2. try-catch的底层执行逻辑异常是如何被抛出来又被接住的2.1 异常对象从throw到catch的完整链路try-catch之所以让人觉得玄是因为很多人没搞懂异常的生命周期。我用最通俗的方式拆解一遍。当代码执行到throw new SomeException()时JVM或运行时环境会做三件事创建一个异常对象这个对象里装着你传入的message还有当时整个调用栈的快照。在当前方法对应的代码块里寻找能匹配的catch分支。如果当前方法里没有匹配的catch异常对象会被抛出到上一层调用者重复第2步直到被捕获或者一路抛到最外层导致进程终止。这个过程叫异常传播。很多人有个误区以为try块里一旦发生异常下面的代码都不执行了整个方法就算结束了。实际上如果这个方法里没有合适的catch方法会立刻从抛出点退出但异常对象还会继续向上走经过每一个可能接住它的try-catch。就像接力棒没人接住就一直滚直到滚出边界。弄懂这个机制你就能理解为什么在哪个层级捕获异常是一个需要深思熟虑的决定。你可以在最底层的方法里catch也可以逐层上抛最终在入口处统一处理。两者的区别在于底层catch能访问到最丰富的本地上下文入口catch则能统一策略减少重复代码。没有绝对的对错只有场景是否合适。2.2 catch块的匹配顺序与多异常分支的设计多catch分支的匹配规则在几乎所有主流语言里都是一致的从上到下、第一个匹配的类型胜出。也就是说如果你把Exception写在NumberFormatException前面那后面的分支永远是死代码因为所有异常都能匹配上Exception。一个经典的设计原则是子类异常写在前面父类异常写在后面。具体到代码里是这样try { parseAndSave(data); } catch (NumberFormatException e) { log.warn(数据格式非法跳过该条{}, data, e); } catch (IllegalArgumentException e) { log.error(参数校验失败{}, e.getMessage(), e); } catch (Exception e) { log.error(未知异常需要人工介入, e); }这里体现了一个思路不同的异常类型代表不同的错误语义应该用不同的处理策略。格式错误可能只是数据脏可以跳过参数校验失败可能是调用方的问题要向上反馈未知异常则是预料之外的情况需要重点记录甚至触发告警。再提一个语言差异。Java 7以后支持multi-catch写起来是这样catch (NumberFormatException | IllegalArgumentException e) { log.error(数据问题{}, e.getMessage(), e); }它适合多种异常用相同方式处理的场景但要注意如果两个异常之间存在继承关系编译器会直接报错因为它知道你写得有歧义。JavaScript和Python里的catch没有类型分支的概念通常是catch到之后自己instanceof判断或者用except (ValueError, TypeError)这种元组写法。语言不同但匹配由近及远的原则是一样的。2.3 finally的执行时机与它存在的意义finally块是最容易被低估的语法。它的定义是无论try块里是正常结束、抛异常、还是被return了finally里的代码都会执行除非发生System.exit()、无限循环或者进程被kill这种极端情况。它的典型用途是释放资源。比如你打开了一个文件流、一个数据库连接在try块里用了它们如果中途抛异常你必须在finally里把它们关掉否则连接就泄漏了。早期代码长这样Connection conn null; try { conn getConnection(); // 执行SQL } finally { if (conn ! null) { conn.close(); } }注意这个例子里我只写了finally没写catch。这其实是很多Java老手的习惯关闭资源是一层独立逻辑它和异常的处理策略不相关。finally保证资源一定被清理至于异常是记录下来还是上抛由catch决定两者可以分开写。这种try-finallycatch的分离写法代码的职责非常清晰。还有个执行顺序的细节如果finally里也有return或throw它会覆盖try块里的return或throw。这个行为前面会细讲反正结论就是不要在finally里写return语句写了的都踩过坑。3. 平时我推荐的try-catch写法从入门到工程化3.1 最基础的try-catch-finally模板先给一个最通用、任何语言都能套用的模板try { // 1. 这里是可能需要保护的业务代码 doSomething(); // 2. 只有上面没有抛异常才能执行到这里 doNext(); } catch (SpecificException e) { // 3. 针对特定异常的处理逻辑 log.error(执行doSomething时发生业务异常, e); // 4. 可以选择恢复、抛出或返回默认值 } finally { // 5. 无论try/catch如何结束都会执行 releaseResources(); }这个模板看起来简单但真正要把它用好有几个容易忽略的点try块的范围要尽量小。这里说的小是指只包含那一段可能抛出特定异常的业务代码不要把整个方法体都塞进去。原因很简单try块越大catch里你能判断到底哪步出了问题的成本就越高。很多人在catch里写e.getMessage()但堆栈信息一长串最后还是要靠人肉分析。catch块必须有实际内容。哪怕只是一行日志也比空着强。日志也不是随便写的要带上当前的上下文参数比如用户ID、订单号否则排查问题的时候无从下手。finally不要写return。这个后面再展开。3.2 多个catch分支与Java 7的multi-catch有经验的架构师在设计异常处理时会倾向于分而治之。同一个try块里不同类型异常的处理策略通常不同可恢复的异常读配置失败用默认配置顶上取缓存失败回源数据库。这种catch之后要给出降级方案。可跳过的异常解析某一行数据失败跳过这一行处理某一条消息失败放入死信队列。这种catch要记录足够的信息确保事后能补偿。不可恢复的异常数据库连接不可用、关键依赖缺失。这种catch要么直接抛出要么记录严重错误并向上汇报避免继续在错误状态下运行。对应到代码里就是前面展示过的多分支结构。这里我再强调一下multi-catch的适用场景如果你这几个catch分支的执行体完全一样才用multi-catch如果执行体不一样老老实实分开写。不要为了少写几行代码把逻辑故意合并代码的可读性比行数重要得多。try { processMessage(msg); } catch (JsonParseException | MessageFormatException e) { handleMalformedMessage(msg, e); }3.3 带资源的try-with-resources与Python的with对比前面提到finally负责关资源但代码写起来总归有点繁琐。Java 7引入了try-with-resources语法只要资源类实现了AutoCloseable接口就可以自动关闭try (Connection conn getConnection(); PreparedStatement stmt conn.prepareStatement(sql)) { // 使用conn和stmt } catch (SQLException e) { log.error(数据库操作失败, e); }这种写法的好处是无论try块是正常结束还是抛异常所有在括号里声明的资源都会按声明逆序自动close你不需要手写finally。比起手动finally这种写法更简洁也让资源泄漏的隐患降到最低。Python里对应的其实是with语句它依赖上下文管理器协议with open(file.txt, r) as f: content f.read()和try-with-resources的思路一样进入with块时获取资源离开块时自动释放即使中间抛了异常也会释放。对比下来你会发现现代语言都在把资源管理从手工try-finally中抽离出来形成语法层面的保障。如果你还在手动close()建议尽快改造。3.4 嵌套try-catch的正确打开方式有时候一个方法里既有外层大操作又有内层小操作于是有人会写出三层嵌套的try-catch看起来像千层蛋糕。嵌套try-catch不是完全不能写但你要清楚它带来的复杂度内层catch处理完异常后外层是否还要处理外层catch捕获到的是内层catch之后的异常还是重新抛出的异常这些都会让阅读代码的人非常费解。我的建议是尽量压平嵌套通过提取方法的方式分离职责。public void processOrder(Order order) { try { validateOrder(order); saveOrder(order); sendNotification(order); } catch (OrderValidationException e) { // 统一处理校验失败 } catch (PersistenceException e) { // 统一处理存储失败 } }如果saveOrder内部还有一步保存订单明细你不应该把保存明细的try-catch写在saveOrder里面然后再抛出来而是让saveOrder自己内部用一个try-catch把明细的异常包装成PersistenceException然后统一传到外层。这样整个方法最多两级每层语义清晰。记住异常处理层数越多代码越难维护能两级解决的问题不要用三级。4. 那些年我们在try-catch里踩过的坑4.1 空catch块异常被吞掉问题被隐藏这是我能列出的try-catch十大反模式之首。catch (Exception e) {}就像把家里烟雾报警器的电池拆了——火灾没有发生之前一切看起来很安静但真烧起来的时候没有任何提醒。空catch块带来的最严重后果不是异常没被处理而是异常信息彻底丢失。堆栈信息是定位异常的唯一钥匙你把它丢掉了就等于让维护者去黑暗里摸开关。更可怕的是很多空catch块还故意不写注释可能是开发时为了先让程序跑通留下的临时代码一忘就是好几年。如果你是自己写代码我强烈建议你在代码仓库的规范里加一条任何人看到空catch块必须将其视为bug。如果你真的认为某个异常可以忽略至少写上注释说明原因并打印一条debug日志。否则你丢的可能是一次事故定位的机会。4.2 catch后记录日志却忘了抛出或恢复的尴尬与空catch相比有一种catch更隐蔽它在catch里打了日志看起来做了点事但实际上既没有抛出异常也没有进行任何恢复操作。这就导致程序继续往后执行而业务逻辑已经进入了一个错误的状态。举个例子public void transfer(Account from, Account to, BigDecimal amount) { try { debit(from, amount); credit(to, amount); } catch (InsufficientBalanceException e) { log.error(扣款失败余额不足, e); } // 这里继续往下执行 notifyUser(转账成功); // 实际上转账根本没成功 }问题一目了然catch里记录完日志但方法没有返回也没有重新抛出异常继续执行了notifyUser。结果用户收到了转账成功的通知钱却一分没动。这种问题比空catch更难发现因为日志里明明有红色error但代码逻辑却完全走偏了。正确的做法有两种一是catch里直接throw一个业务异常让上层感知二是catch里处理好降级逻辑后return明确告诉后续代码这条路没走通。无论如何不要让异常之后的代码在假装正常的状态下继续跑。4.3 finally块里的return和throw会覆盖原有结果这个坑在Java面试里出现过无数次但实际工程里依然偶发生。给你看一段代码public String readConfig(String key) { try { return configMap.get(key); } finally { return default; } }试想如果configMap.get(key)返回了值执行到finally里直接return default那方法返回的结果永远是default你辛苦读到的真实配置被无意识丢弃了。如果configMap.get(key)抛了异常finally里的return default也会把这个异常彻底覆盖调用方看到的是一切正常却不知道内部早已出错。finally的职责是清理资源不是决定返回值。哪怕你想在异常时返回默认值也应该写在catch块里而不是finally里。同样的道理适用于finally里的throw它会覆盖try里已经抛出的异常让真实的异常信息丢失。记住一个原则finally里不要写return不要写throw。4.4 在循环里滥用try-catch的性能与逻辑问题有人习惯在for循环内部给每次迭代都套上一个try-catch目的是防止一条数据坏了影响整批。这个初衷没错但实现方式值得推敲。从性能角度讲异常抛出的成本很高因为它要填充堆栈信息。如果循环里有一百万条数据其中有几条必然抛异常那这几条的成本可以忽略不计但如果代码写得不好用异常来控制正常流程见第5节那性能会非常难看。从逻辑角度讲循环内try-catch有一个好处可以精确捕获当前迭代的位置和上下文。但如果你把整个循环体放在一个大的try-catch里一旦某条数据抛异常后面所有的数据都没机会处理了。这就有个权衡问题。我的习惯是如果单条数据的处理逻辑比较复杂就抽取成一个独立方法方法内部自己try-catch如果只是简单的解析或校验可以在循环体内用try-catch但catch之后一定要continue或break明确方向并且把失败的数据记录下来方便事后补偿。for (String line : lines) { try { processLine(line); } catch (LineParseException e) { failedLines.add(line); log.warn(跳过异常行{}原因{}, line, e.getMessage()); } }这样既保证了批量数据的完整性又把失败数据单独留存比整批失败好得多。5. 什么场景不该用try-catch反模式与重构思路5.1 用异常做流程控制与if-else的本质区别有些代码从远处一看就浑身难受try { Integer.parseInt(input); // 走到这里说明input能转成数字 handleNumber(input); } catch (NumberFormatException e) { // 走这里说明input不是数字 handleText(input); }这里把try-catch当成了isNumber判断用异常分支来控制流程走向。问题在于异常机制的设计初衷是为了处理预期之外、非正常的错误情况而input不是数字完全可以通过正则表达式或Character.isDigit提前判断出来它是一个正常的业务分支不该走异常通道。用异常做流程控制的代价有两个一是可读性差维护者需要仔细推理try和catch的边界二是性能损耗创建异常对象和填充堆栈是很昂贵的操作。所以在写try-catch之前先问自己这个异常真的是异常还是业务分支如果是业务分支用if-else如果是不可预料的错误才用try-catch。5.2 大范围catch(Exception)的设计边界catch (Exception e)这种写法本身并不算错但要看放在哪里。放在程序的入口处比如Controller层、消息队列消费的顶层、定时任务的入口是合理的因为你希望兜住所有未预料到的异常避免进程崩溃。但如果你在每一个Service层方法上都来一个catch (Exception e)那问题就大了。这样的代码事实上把方法内部可能发生的所有异常都拦截下来然后统一打一行日志。你会失去异常是从哪个业务分支冒出来的这一层信息。而且Exception还包含了RuntimeException、NullPointerException这些本应通过修复代码消除的bug型异常把它们都捕获了等于屏蔽了代码质量问题。我的建议是分层处理业务代码层尽量捕获特定异常类型能精确就精确处理完后要么抛出业务异常要么转换后向上抛。框架入口层统一catch所有的Exception记录错误日志转换为用户友好的提示或系统级告警。记住一句话越是底层的代码catch的类型越要精确越是最顶层的代码catch的范围才可以越大。5.3 从try-catch到异常设计何时抛出、何时吞掉、何时转换最后聊一点更进阶的内容。异常处理不应该写得哪儿都是而应该有一套统一的设计思路。我通常按三步来思考这个错误是否应该在这里处理如果当前方法有足够的信息来恢复就catch并处理如果当前方法根本不具备处理条件就不要过早catch直接向外抛出让上层自己决定。抛出时应该抛什么异常尽量抛有业务语义的异常比如OrderNotFoundException、PaymentFailedException而不是空泛的Exception。如果是为了处理底层异常可以把它包装成自定义异常同时保留原始异常作为cause。处理之后应该返回什么如果确定要吞掉异常必须记录日志并返回一个降级结果。最忌讳的是既不产出任何结果也不告知任何人。举个例子public User getUserOrNull(Long userId) { try { return userRepository.findById(userId); } catch (DataAccessException e) { log.error(查询用户失败userId{}, userId, e); return null; } }这里吞掉异常是主动选择因为调用方需要的是查不到就返回null但日志保留了下原因这就是吞得明白。另一种public User getUser(Long userId) { try { return userRepository.findById(userId); } catch (DataAccessException e) { throw new BizException(查询用户失败, e); } }底层异常被转换为业务异常同时保留了原始堆栈这就是转换得清楚。两种写法没有高下之分取决于API的契约设计。你要做的就是让吞和抛都变成显式的设计决策而不是随手一写。5.4 我个人在项目里的异常处理小模板最后分享一个我从多个项目里沉淀下来的模板。不一定适用于所有团队但对中小型项目来说很实用。我习惯把try-catch做成一个兜底安全网而不是到处撒网。具体来说Service层每个方法只捕获那些能够降级或重试的异常其他的全部向上抛。Controller层或MQ consumer入口处用一个全局异常处理器统一捕获转换成统一响应体。在关键路径上我会定义一个简单的SneakyTry工具类用函数式接口封装可能异常的代码块让业务代码保持干净。以Java为例简单版FunctionalInterface public interface ThrowableSupplierT { T get() throws Exception; } public static T T tryOrNull(ThrowableSupplierT supplier) { try { return supplier.get(); } catch (Exception e) { log.error(执行失败返回null, e); return null; } }然后用起来就是一行User user tryOrNull(() - userService.getUser(userId)); if (user null) { // 降级逻辑 }当然这种工具不能滥用它本质上是吞异常的封装用多了会掩盖问题。我的经验是它适合用在非关键路径、失败可以降级的场景核心业务必须自己显式处理异常。做异常处理设计这么多年我最大的体会是try-catch的语法一学就会但该在什么地方接住异常、接住之后做什么才是真正考验设计能力的地方。试着在每次写try-catch时多问自己一句这个异常接住之后我是让它安静地消失还是让它变成下一次改版的线索多问几次你的代码质量会有明显不同。
处理线上问题时我最怕看到这样的代码catch (Exception e) {}——一个空catch块像一个沉默的嫌疑人异常被接住了但什么也没做问题就像沉入深海。这就是我今天想聊的try-catch使用。try-catch几乎是所有编程语言里最基础的语法之一但它绝不是把可能出错的代码包起来这么简单。很多人写了几年代码依然会在异常处理上栽跟头。这篇文章我想从底层执行逻辑、工程化写法、常见陷阱到异常设计把try-catch这件事一次说透。不管是刚入门的新人还是有几年经验的开发者应该都能从中找到一些值得回味的细节。1. 先从一次线上事故说起try-catch到底在保护什么1.1 没有try-catch时一次异常会发生什么去年我们团队出过一个事故一个定时报表任务每天晚上聚合全量数据跑完大概要四十分钟。某天凌晨数据源里混入一条格式异常的记录解析到那一行时抛了个NumberFormatException整个任务直接中断日志里留下一大段堆栈信息然后线程死了。第二天业务方发现报表没生成问了一圈最后查日志才定位到是那条脏数据。这个问题更让人头疼的不是异常本身而是它造成的连锁反应任务中断后没有重试机制也没人收到报警数据链路整段缺失。假如当时代码里用了try-catch把单条解析失败这个错误隔离出来记录失败原因后跳过后续的数据仍然能正常处理事故就只是一条warning日志的事。这个例子说明了一个核心事实try-catch的第一层价值是隔离故障。它不是让错误不发生而是让错误的影响面积可控。程序运行过程中IO异常、格式异常、网络超时、空指针这些运行时错误永远不可能靠代码审查全部消灭。如果没有try-catch任何一个微小的异常都有可能引爆整个进程让服务直接宕机。1.2 try-catch真正解决的三个问题很多人对try-catch的理解停留在防止程序崩溃上这个理解没错但太片面。按我自己的工程经验try-catch实际解决了三个层次的问题保证程序不因为局部错误整体终止这是最底层的保护。某个操作失败至少不能让整个服务挂掉这是生产环境最基本的底线。提供稳定的反馈路径用户的请求因为参数问题抛异常如果直接让页面变成500空页面体验很差。通过catch捕获后你可以给用户返回一个友好的错误提示或者返回一个默认值这是降级反馈。保留足够的诊断上下文异常对象本身携带了堆栈信息能告诉开发人员哪里出了问题。配合日志采集你可以通过一条error日志快速定位到具体代码行。如果连catch都没有你连定位问题的入口都找不到。三个层次对应的是稳定性、可交互性和可排查性。你写try-catch时应该时刻问自己这一层保护解决的是这三个问题里的哪一个如果一个问题都不解决那这个try-catch大概率是多余的甚至是隐患。2. try-catch的底层执行逻辑异常是如何被抛出来又被接住的2.1 异常对象从throw到catch的完整链路try-catch之所以让人觉得玄是因为很多人没搞懂异常的生命周期。我用最通俗的方式拆解一遍。当代码执行到throw new SomeException()时JVM或运行时环境会做三件事创建一个异常对象这个对象里装着你传入的message还有当时整个调用栈的快照。在当前方法对应的代码块里寻找能匹配的catch分支。如果当前方法里没有匹配的catch异常对象会被抛出到上一层调用者重复第2步直到被捕获或者一路抛到最外层导致进程终止。这个过程叫异常传播。很多人有个误区以为try块里一旦发生异常下面的代码都不执行了整个方法就算结束了。实际上如果这个方法里没有合适的catch方法会立刻从抛出点退出但异常对象还会继续向上走经过每一个可能接住它的try-catch。就像接力棒没人接住就一直滚直到滚出边界。弄懂这个机制你就能理解为什么在哪个层级捕获异常是一个需要深思熟虑的决定。你可以在最底层的方法里catch也可以逐层上抛最终在入口处统一处理。两者的区别在于底层catch能访问到最丰富的本地上下文入口catch则能统一策略减少重复代码。没有绝对的对错只有场景是否合适。2.2 catch块的匹配顺序与多异常分支的设计多catch分支的匹配规则在几乎所有主流语言里都是一致的从上到下、第一个匹配的类型胜出。也就是说如果你把Exception写在NumberFormatException前面那后面的分支永远是死代码因为所有异常都能匹配上Exception。一个经典的设计原则是子类异常写在前面父类异常写在后面。具体到代码里是这样try { parseAndSave(data); } catch (NumberFormatException e) { log.warn(数据格式非法跳过该条{}, data, e); } catch (IllegalArgumentException e) { log.error(参数校验失败{}, e.getMessage(), e); } catch (Exception e) { log.error(未知异常需要人工介入, e); }这里体现了一个思路不同的异常类型代表不同的错误语义应该用不同的处理策略。格式错误可能只是数据脏可以跳过参数校验失败可能是调用方的问题要向上反馈未知异常则是预料之外的情况需要重点记录甚至触发告警。再提一个语言差异。Java 7以后支持multi-catch写起来是这样catch (NumberFormatException | IllegalArgumentException e) { log.error(数据问题{}, e.getMessage(), e); }它适合多种异常用相同方式处理的场景但要注意如果两个异常之间存在继承关系编译器会直接报错因为它知道你写得有歧义。JavaScript和Python里的catch没有类型分支的概念通常是catch到之后自己instanceof判断或者用except (ValueError, TypeError)这种元组写法。语言不同但匹配由近及远的原则是一样的。2.3 finally的执行时机与它存在的意义finally块是最容易被低估的语法。它的定义是无论try块里是正常结束、抛异常、还是被return了finally里的代码都会执行除非发生System.exit()、无限循环或者进程被kill这种极端情况。它的典型用途是释放资源。比如你打开了一个文件流、一个数据库连接在try块里用了它们如果中途抛异常你必须在finally里把它们关掉否则连接就泄漏了。早期代码长这样Connection conn null; try { conn getConnection(); // 执行SQL } finally { if (conn ! null) { conn.close(); } }注意这个例子里我只写了finally没写catch。这其实是很多Java老手的习惯关闭资源是一层独立逻辑它和异常的处理策略不相关。finally保证资源一定被清理至于异常是记录下来还是上抛由catch决定两者可以分开写。这种try-finallycatch的分离写法代码的职责非常清晰。还有个执行顺序的细节如果finally里也有return或throw它会覆盖try块里的return或throw。这个行为前面会细讲反正结论就是不要在finally里写return语句写了的都踩过坑。3. 平时我推荐的try-catch写法从入门到工程化3.1 最基础的try-catch-finally模板先给一个最通用、任何语言都能套用的模板try { // 1. 这里是可能需要保护的业务代码 doSomething(); // 2. 只有上面没有抛异常才能执行到这里 doNext(); } catch (SpecificException e) { // 3. 针对特定异常的处理逻辑 log.error(执行doSomething时发生业务异常, e); // 4. 可以选择恢复、抛出或返回默认值 } finally { // 5. 无论try/catch如何结束都会执行 releaseResources(); }这个模板看起来简单但真正要把它用好有几个容易忽略的点try块的范围要尽量小。这里说的小是指只包含那一段可能抛出特定异常的业务代码不要把整个方法体都塞进去。原因很简单try块越大catch里你能判断到底哪步出了问题的成本就越高。很多人在catch里写e.getMessage()但堆栈信息一长串最后还是要靠人肉分析。catch块必须有实际内容。哪怕只是一行日志也比空着强。日志也不是随便写的要带上当前的上下文参数比如用户ID、订单号否则排查问题的时候无从下手。finally不要写return。这个后面再展开。3.2 多个catch分支与Java 7的multi-catch有经验的架构师在设计异常处理时会倾向于分而治之。同一个try块里不同类型异常的处理策略通常不同可恢复的异常读配置失败用默认配置顶上取缓存失败回源数据库。这种catch之后要给出降级方案。可跳过的异常解析某一行数据失败跳过这一行处理某一条消息失败放入死信队列。这种catch要记录足够的信息确保事后能补偿。不可恢复的异常数据库连接不可用、关键依赖缺失。这种catch要么直接抛出要么记录严重错误并向上汇报避免继续在错误状态下运行。对应到代码里就是前面展示过的多分支结构。这里我再强调一下multi-catch的适用场景如果你这几个catch分支的执行体完全一样才用multi-catch如果执行体不一样老老实实分开写。不要为了少写几行代码把逻辑故意合并代码的可读性比行数重要得多。try { processMessage(msg); } catch (JsonParseException | MessageFormatException e) { handleMalformedMessage(msg, e); }3.3 带资源的try-with-resources与Python的with对比前面提到finally负责关资源但代码写起来总归有点繁琐。Java 7引入了try-with-resources语法只要资源类实现了AutoCloseable接口就可以自动关闭try (Connection conn getConnection(); PreparedStatement stmt conn.prepareStatement(sql)) { // 使用conn和stmt } catch (SQLException e) { log.error(数据库操作失败, e); }这种写法的好处是无论try块是正常结束还是抛异常所有在括号里声明的资源都会按声明逆序自动close你不需要手写finally。比起手动finally这种写法更简洁也让资源泄漏的隐患降到最低。Python里对应的其实是with语句它依赖上下文管理器协议with open(file.txt, r) as f: content f.read()和try-with-resources的思路一样进入with块时获取资源离开块时自动释放即使中间抛了异常也会释放。对比下来你会发现现代语言都在把资源管理从手工try-finally中抽离出来形成语法层面的保障。如果你还在手动close()建议尽快改造。3.4 嵌套try-catch的正确打开方式有时候一个方法里既有外层大操作又有内层小操作于是有人会写出三层嵌套的try-catch看起来像千层蛋糕。嵌套try-catch不是完全不能写但你要清楚它带来的复杂度内层catch处理完异常后外层是否还要处理外层catch捕获到的是内层catch之后的异常还是重新抛出的异常这些都会让阅读代码的人非常费解。我的建议是尽量压平嵌套通过提取方法的方式分离职责。public void processOrder(Order order) { try { validateOrder(order); saveOrder(order); sendNotification(order); } catch (OrderValidationException e) { // 统一处理校验失败 } catch (PersistenceException e) { // 统一处理存储失败 } }如果saveOrder内部还有一步保存订单明细你不应该把保存明细的try-catch写在saveOrder里面然后再抛出来而是让saveOrder自己内部用一个try-catch把明细的异常包装成PersistenceException然后统一传到外层。这样整个方法最多两级每层语义清晰。记住异常处理层数越多代码越难维护能两级解决的问题不要用三级。4. 那些年我们在try-catch里踩过的坑4.1 空catch块异常被吞掉问题被隐藏这是我能列出的try-catch十大反模式之首。catch (Exception e) {}就像把家里烟雾报警器的电池拆了——火灾没有发生之前一切看起来很安静但真烧起来的时候没有任何提醒。空catch块带来的最严重后果不是异常没被处理而是异常信息彻底丢失。堆栈信息是定位异常的唯一钥匙你把它丢掉了就等于让维护者去黑暗里摸开关。更可怕的是很多空catch块还故意不写注释可能是开发时为了先让程序跑通留下的临时代码一忘就是好几年。如果你是自己写代码我强烈建议你在代码仓库的规范里加一条任何人看到空catch块必须将其视为bug。如果你真的认为某个异常可以忽略至少写上注释说明原因并打印一条debug日志。否则你丢的可能是一次事故定位的机会。4.2 catch后记录日志却忘了抛出或恢复的尴尬与空catch相比有一种catch更隐蔽它在catch里打了日志看起来做了点事但实际上既没有抛出异常也没有进行任何恢复操作。这就导致程序继续往后执行而业务逻辑已经进入了一个错误的状态。举个例子public void transfer(Account from, Account to, BigDecimal amount) { try { debit(from, amount); credit(to, amount); } catch (InsufficientBalanceException e) { log.error(扣款失败余额不足, e); } // 这里继续往下执行 notifyUser(转账成功); // 实际上转账根本没成功 }问题一目了然catch里记录完日志但方法没有返回也没有重新抛出异常继续执行了notifyUser。结果用户收到了转账成功的通知钱却一分没动。这种问题比空catch更难发现因为日志里明明有红色error但代码逻辑却完全走偏了。正确的做法有两种一是catch里直接throw一个业务异常让上层感知二是catch里处理好降级逻辑后return明确告诉后续代码这条路没走通。无论如何不要让异常之后的代码在假装正常的状态下继续跑。4.3 finally块里的return和throw会覆盖原有结果这个坑在Java面试里出现过无数次但实际工程里依然偶发生。给你看一段代码public String readConfig(String key) { try { return configMap.get(key); } finally { return default; } }试想如果configMap.get(key)返回了值执行到finally里直接return default那方法返回的结果永远是default你辛苦读到的真实配置被无意识丢弃了。如果configMap.get(key)抛了异常finally里的return default也会把这个异常彻底覆盖调用方看到的是一切正常却不知道内部早已出错。finally的职责是清理资源不是决定返回值。哪怕你想在异常时返回默认值也应该写在catch块里而不是finally里。同样的道理适用于finally里的throw它会覆盖try里已经抛出的异常让真实的异常信息丢失。记住一个原则finally里不要写return不要写throw。4.4 在循环里滥用try-catch的性能与逻辑问题有人习惯在for循环内部给每次迭代都套上一个try-catch目的是防止一条数据坏了影响整批。这个初衷没错但实现方式值得推敲。从性能角度讲异常抛出的成本很高因为它要填充堆栈信息。如果循环里有一百万条数据其中有几条必然抛异常那这几条的成本可以忽略不计但如果代码写得不好用异常来控制正常流程见第5节那性能会非常难看。从逻辑角度讲循环内try-catch有一个好处可以精确捕获当前迭代的位置和上下文。但如果你把整个循环体放在一个大的try-catch里一旦某条数据抛异常后面所有的数据都没机会处理了。这就有个权衡问题。我的习惯是如果单条数据的处理逻辑比较复杂就抽取成一个独立方法方法内部自己try-catch如果只是简单的解析或校验可以在循环体内用try-catch但catch之后一定要continue或break明确方向并且把失败的数据记录下来方便事后补偿。for (String line : lines) { try { processLine(line); } catch (LineParseException e) { failedLines.add(line); log.warn(跳过异常行{}原因{}, line, e.getMessage()); } }这样既保证了批量数据的完整性又把失败数据单独留存比整批失败好得多。5. 什么场景不该用try-catch反模式与重构思路5.1 用异常做流程控制与if-else的本质区别有些代码从远处一看就浑身难受try { Integer.parseInt(input); // 走到这里说明input能转成数字 handleNumber(input); } catch (NumberFormatException e) { // 走这里说明input不是数字 handleText(input); }这里把try-catch当成了isNumber判断用异常分支来控制流程走向。问题在于异常机制的设计初衷是为了处理预期之外、非正常的错误情况而input不是数字完全可以通过正则表达式或Character.isDigit提前判断出来它是一个正常的业务分支不该走异常通道。用异常做流程控制的代价有两个一是可读性差维护者需要仔细推理try和catch的边界二是性能损耗创建异常对象和填充堆栈是很昂贵的操作。所以在写try-catch之前先问自己这个异常真的是异常还是业务分支如果是业务分支用if-else如果是不可预料的错误才用try-catch。5.2 大范围catch(Exception)的设计边界catch (Exception e)这种写法本身并不算错但要看放在哪里。放在程序的入口处比如Controller层、消息队列消费的顶层、定时任务的入口是合理的因为你希望兜住所有未预料到的异常避免进程崩溃。但如果你在每一个Service层方法上都来一个catch (Exception e)那问题就大了。这样的代码事实上把方法内部可能发生的所有异常都拦截下来然后统一打一行日志。你会失去异常是从哪个业务分支冒出来的这一层信息。而且Exception还包含了RuntimeException、NullPointerException这些本应通过修复代码消除的bug型异常把它们都捕获了等于屏蔽了代码质量问题。我的建议是分层处理业务代码层尽量捕获特定异常类型能精确就精确处理完后要么抛出业务异常要么转换后向上抛。框架入口层统一catch所有的Exception记录错误日志转换为用户友好的提示或系统级告警。记住一句话越是底层的代码catch的类型越要精确越是最顶层的代码catch的范围才可以越大。5.3 从try-catch到异常设计何时抛出、何时吞掉、何时转换最后聊一点更进阶的内容。异常处理不应该写得哪儿都是而应该有一套统一的设计思路。我通常按三步来思考这个错误是否应该在这里处理如果当前方法有足够的信息来恢复就catch并处理如果当前方法根本不具备处理条件就不要过早catch直接向外抛出让上层自己决定。抛出时应该抛什么异常尽量抛有业务语义的异常比如OrderNotFoundException、PaymentFailedException而不是空泛的Exception。如果是为了处理底层异常可以把它包装成自定义异常同时保留原始异常作为cause。处理之后应该返回什么如果确定要吞掉异常必须记录日志并返回一个降级结果。最忌讳的是既不产出任何结果也不告知任何人。举个例子public User getUserOrNull(Long userId) { try { return userRepository.findById(userId); } catch (DataAccessException e) { log.error(查询用户失败userId{}, userId, e); return null; } }这里吞掉异常是主动选择因为调用方需要的是查不到就返回null但日志保留了下原因这就是吞得明白。另一种public User getUser(Long userId) { try { return userRepository.findById(userId); } catch (DataAccessException e) { throw new BizException(查询用户失败, e); } }底层异常被转换为业务异常同时保留了原始堆栈这就是转换得清楚。两种写法没有高下之分取决于API的契约设计。你要做的就是让吞和抛都变成显式的设计决策而不是随手一写。5.4 我个人在项目里的异常处理小模板最后分享一个我从多个项目里沉淀下来的模板。不一定适用于所有团队但对中小型项目来说很实用。我习惯把try-catch做成一个兜底安全网而不是到处撒网。具体来说Service层每个方法只捕获那些能够降级或重试的异常其他的全部向上抛。Controller层或MQ consumer入口处用一个全局异常处理器统一捕获转换成统一响应体。在关键路径上我会定义一个简单的SneakyTry工具类用函数式接口封装可能异常的代码块让业务代码保持干净。以Java为例简单版FunctionalInterface public interface ThrowableSupplierT { T get() throws Exception; } public static T T tryOrNull(ThrowableSupplierT supplier) { try { return supplier.get(); } catch (Exception e) { log.error(执行失败返回null, e); return null; } }然后用起来就是一行User user tryOrNull(() - userService.getUser(userId)); if (user null) { // 降级逻辑 }当然这种工具不能滥用它本质上是吞异常的封装用多了会掩盖问题。我的经验是它适合用在非关键路径、失败可以降级的场景核心业务必须自己显式处理异常。做异常处理设计这么多年我最大的体会是try-catch的语法一学就会但该在什么地方接住异常、接住之后做什么才是真正考验设计能力的地方。试着在每次写try-catch时多问自己一句这个异常接住之后我是让它安静地消失还是让它变成下一次改版的线索多问几次你的代码质量会有明显不同。
