在深夜的办公室里或者是凌晨三点被刺耳的告警

回想一下刚入门编程的时候，我们是不是dou写过类似这样的代码？为了验证一个变量是不是空的，随手就在代码里加一句 System.out.println，或者在 catch 块里打印一句“出错了”。这种Zuo法在写“Hello World”的时候或许无伤大雅，但在真实的企业级项目中，这简直就是灾难。

为什么这么说？因为 System.out 是一个同步阻塞的操作。当你频繁地使用它时它不仅会拖慢系统的性Neng，geng重要的是它输出的信息往往没有上下文。你只kan到了“出现了数值转化异常”，但你不知道是哪一次请求触发的，也不知道当时的用户ID是多少。geng致命的是标准输出流可Neng根本就没有被重定向到日志文件里这意味着当服务器崩溃重启后那些宝贵的现场证据就这样随风而逝了。

所以第一条铁律就是：彻底告别 System.out.println 和 e.printStackTrace。拥抱专业的日志框架，比如SLF4J配合Logback，或者Log4j2。它们不仅Neng异步写入，还Neng帮你控制日志级别，甚至按天滚动归档，这才是成熟项目该有的样子。

在决定是打印日志还是抛出错误之前，我们必须先搞清楚一个核心概念：你遇到的这个异常，到底是谁的错？这听起来像是在推卸责任，但在软件架构中，这直接决定了处理策略。通常，我们将异常分为两大类：业务异常和系统异常。

什么是业务异常？简单来说就是用户“不按套路出牌”导致的错误。比如用户注册时密码留空了、下单时商品数量填了负数、或者查询一个根本不存在的订单ID。这些情况虽然也是“错误”，但它们是业务逻辑中完全Ke以预见的一部分。

对于这类异常，千万不要打印 error 级别的日志！ 为什么？试想一下Ru果双十一那天有几万个用户手滑输错了验证码，你的服务器日志里是不是就要瞬间多出几万条ERROR记录？这会导致你的日志告警系统疯狂报警，运维人员会被这些无效信息淹没，从而可Neng错过真正严重的系统故障。

正确的Zuo法是：直接抛出一个自定义的业务异常，比如 BizException 或 IllegalArgumentException，并附带友好的提示信息。代码大概长这样：

public Order createOrder {
    // 这里的判断是业务逻辑的一部分
    if  == null) {
        // ✅ 只抛出业务异常，告诉上层调用者哪里Zuo错了
        // 绝对不要在这里打 log.error，这不算系统故障！
        throw new BizException;
    }
    if  <= 0) {
        throw new BizException;
    }
    // 一切正常，执行数据库插入
    return orderMapper.insert;
}

kan到那个注释了吗？“不打log.error”。这就是关键。这种异常是给用户kan的，或者是给调用方用来判断逻辑走向的，它们是流程控制的一部分，而不是系统的意外。

那么什么时候才需要我们紧张地打印日志呢？答案是系统异常。这类异常通常是由于底层资源问题、代码逻辑缺陷、或者第三方服务不可用引起的。比如数据库连接池耗尽、Redis突然挂了、或者代码里不小心除以了零。

这时候，情况就完全不同了。这不再是用户的问题，而是我们的程序“生病”了。我们需要尽可Neng多地保留现场信息，以便事后复盘。因此，必须打印 error 日志，并且要带上完整的堆栈信息。

kankan下面这个查询订单的例子：

@Service
public class OrderService {
    private static final Logger log = LoggerFactory.getLogger;
    public Order getOrder {
        try {
            // 这里可Neng会发生各种不可预知的事情：数据库宕机、网络超时...
            return orderMapper.selectById;
        } catch  {
            // ✅ 必须动作：记录详细的错误日志，包括入参和异常堆栈
            log.error;
            // ✅ 然后抛出一个封装好的系统异常，不要把底层的 SQLException 暴露给前端
            throw new SystemException;
        }
    }
}

注意这里的 log.error，我们把 orderId 也放进去了。这一点至关重要！Ru果你只打印了异常堆栈，却不知道是哪个订单触发的异常，那排查问题的难度将呈指数级上升。另外抛给前端的异常信息要模糊处理，比如“系统繁忙”，避免暴露数据库表结构等敏感信息。

Ru果我们在每个方法里dou写大量的 try-catch，代码不仅变得臃肿难kan，还容易漏掉某些异常。这时候，Spring Boot 提供的 @RestControllerAdvice 就成了我们的救星。它就像一个全局的守门员，Neng把所有漏网之鱼一网打尽。

我们Ke以定义一个全局异常处理类，把刚才提到的两种策略完美地融合在一起：

// 全局异常处理类
@RestControllerAdvice
public class GlobalExceptionHandler {
    // 专门捕获
    @ExceptionHandler
    public Result handleBizException {
        // 这里通常打 warn 级别即可，或者不打日志，视业务监控需求而定
        log.warn);
        // 直接把错误信息返回给前端，让用户知道怎么改
        return Result.fail);
    }
    // 捕获
    @ExceptionHandler
    public Result handleException {
        // 这里才是真正的 error！
        log.error;
        // 给用户一个通用的回复，保持神秘感
        return Result.fail;
    }
}

有了这个机制，我们的业务代码就Ke以变得非常清爽。大部分情况下我们不需要在 Service 层写任何 try-catch。Ru果是业务校验不通过直接 throw new BizException；Ru果是数据库操作失败，框架会自动捕获并记录日志。这种分层处理的思想，Neng让代码的可维护性提升一个档次。

当然实际的项目开发往往比教科书要复杂得多。有时候，我们并不是简单地“打印”或“抛出”，而是需要结合场景Zuo一些补偿操作。

比如当你调用第三方支付接口时Ru果抛出了网络超时异常。这时候，仅仅打印日志可Neng不够，你可Neng需要触发一个重试机制，或者把这笔任务先扔到消息队列里等会儿再异步处理。又或者，在一个批量处理数据的循环中，某一条数据解析失败了你是要直接抛出异常让整个任务停止，还是 catch 住这个异常，记录下来然后继续处理下一条数据？

这就需要我们根据具体的业务需求来灵活变通了。有时候，我们会把异常对象先放到一个集合里存着，等循环结束后统一收集这些错误信息一次性返回给用户。这种“吞掉异常但记录在案”的Zuo法，在批量导入数据的场景下非常常见。

还有一点容易被忽视的是事务回滚。catch 块里Ru果Zuo了日志记录，记得一定要考虑清楚是否需要继续抛出异常，或者手动设置回滚状态。

说了这么多，其实核心思想就一句话：不要把异常当成洪水猛兽，也不要把它们当成耳旁风。

打印日志和抛出错误，本质上是在和未来的自己、和接手你代码的同事、和运维人员对话。当你写下 log.error 的时候，你是在说：“嘿，这里出问题了快来kankan！”当你抛出 BizException 的时候，你是在告诉用户：“对不起，你的请求有点问题，请修正一下。”

区分清楚业务异常和系统异常，善用全局处理器，抛弃原始的控制台输出。这些kan似微小的习惯，积累起来就是项目质量的巨大飞跃。毕竟谁也不想在一个风和日丽的周末，因为日志里缺失的一行关键信息，而被叫回公司加班修Bug，对吧？

希望这篇文章Neng让你在下次面对那个红色的报错弹窗时Neng多一份从容，少一份焦虑。写出优雅的异常处理代码，从现在开始。