删掉80%的try-catch，系统geng稳了？

刚入行那会儿，我写 Java 代码有个“强迫症”：每个方法dou包一层 try-catch，生怕程序崩溃。kan起来hen负责？其实这是在给系统埋雷。

直到去年一个线上事故，我才彻底醒悟：乱用 try-catch，比不处理异常geng危险。 我们有个订单导出功Neng，因为 getUserById 在异常时返回 null，而下游代码没判空，直接调用了 user.getName —— 结果 NPE，整个导出任务中断。

异常是系统的“警报器”。你把它 catch 了又不Zuo有效处理，等于把警报关了但火还在烧。上游调用者以为方法执行成功了结果拿到一个 null，后续逻辑全乱套。这比直接抛异常geng难排查。

Ru果你用 APM或 ELK Zuo异常监控，被吞掉的异常根本不会上报。等你发现时可NengYi经影响成千上万用户。

我的原则就一条：只在你Neng真正“处理”异常的地方 catch 它。 什么叫“Neng处理”？举几个例子：

读取配置文件失败，你Ke以自定义一个 ConfigLoadException，并在方法签名 throws 出去。调用方必须面对它，而不是假装没事发生。

Ru果真要在中间层记录日志，一定要带上关键参数。这样排查时直接搜 orderId 就Neng找到完整链路。

try { processOrder;} catch { log.error; // 关键！ throw e; // 别吞掉，继续抛}

Spring Boot 里用 @ControllerAdvice 全局处理异常，既干净又可控：

@RestControllerAdvicepublic class GlobalExceptionHandler { @ExceptionHandler public ResponseEntity<ErrorResponse> handleUserNotFound { return ResponseEntity.status.body)); } @ExceptionHandler public ResponseEntity<ErrorResponse> handleUnexpected { log.error; // 这里才该打 error 日志！ return ResponseEntity.status.body); }}

这样，Service 层完全不用写 try-catch，专注业务逻辑。出问题时日志清晰、响应规范、监控也Neng抓到。

删掉80%的try-catch，并不是说不用异常处理，而是要合理使用 try-catch。

NPE、非法参数这类编程错误，要快速失败，别吞掉。

I/O 操作、RPC 调用这类可Neng失败的操作，该 try-catch 就 try-catch，但别吃掉异常，要么往上抛，要么有补偿机制。

@ControllerAdvice 全局捕获，让 Controller 层代码清爽，也统一了错误响应格式。

MDC/ELK/APM 上报，让每个异常dou有“身份证”，方便追踪和统计。

"合理使用 try-catch"并不简单，需要根据具体场景和业务需求进行权衡。通过上述的方式，Ke以让我们的代码geng加健壮，同时也geng容易维护和排查问题。 在实践中不断和优化，你的代码质量也会越来越高！👍