Java里什么时候不建议用异常_Java异常使用误区说明_网络技术

发布时间 - 2026-01-21 00:00:00 点击率：次

不建议用异常控制正常业务流程，因性能开销大、掩盖设计问题；应将可预期失败转为返回值或状态码，异常仅用于真正意外场景，并需分层定义、规范日志与处理。

Java里不建议用异常来控制正常业务流程，比如用try-catch代替条件判断、用抛异常实现逻辑跳转、或在高频调用路径中频繁抛出检查型异常。异常机制本身开销大，且会掩盖真实设计问题。

常见错误：为避免写多个if，把“值不存在”“参数非法”等预期情况包装成异常，再靠catch捕获处理。

检查型异常（Checked Exception）强制调用方处理，但若在for循环内每次IO或转换都抛IOException或ParseException，代码会变得臃肿且难维护。

例如：解析1000条日志行，每行可能格式错误——应统一收集错误行并记录，而不是每错一行就抛一次异常再try-catch
又如：数据库批量插入时个别记录违反唯一约束，适合用ON CONFLICT DO NOTHING或批量返回失败索引，而非逐条执行+捕获SQLException
关键点：异常用于“意外”，不是“常见失败”。高频、可预期的失败应设计为返回值或状态码

随便封装一个BusinessException扔到处抛，却不说明具体上下文，会让调用方无法针对性处理。

避免：所有业务错误都抛同一个MyAppException，连HTTP状态码、重试建议、日志级别都无差异
推荐：按场景分层，如UserNotFoundException（404）、InsufficientBalanceException（400）、PaymentTimeoutException（504），并在构造时传入traceId和原始原因
注意：不要用异常传递业务数据（如把订单ID塞进message字段），应通过字段或独立对象承载

这是最隐蔽也最危险的误区——吞掉异常等于隐藏系统缺陷。

典型反模式：catch (Exception e) { e.printStackTrace(); }，既没记录日志级别，
也没补偿动作，更没向上抛或通知监控
正确做法：至少用SLF4J打ERROR日志，并包含关键上下文（如用户ID、请求ID、操作类型）；对可恢复异常（如网络抖动）考虑重试；对不可恢复的，明确返回失败结果
特别提醒：空catch块在静态扫描工具（如SonarQube）中会被标为严重漏洞