一个文件导入功能看上去很简单打开文件、逐行解析、写入数据库、返回结果。但一旦文件编码不对、某行格式错误、写库失败或关闭文件时再次出错异常设计就会直接决定系统是否能够定位问题、能否安全重试以及用户能否知道失败发生在什么位置。好的异常处理并不是到处加try-catch而是在恰当的边界保留上下文并做出清楚的决策。一、异常不是日志的同义词下面这种代码看似处理了错误实际上让调用者误以为任务成功try{importFile(path);}catch(Exceptione){log.error(导入失败,e);}returnImportResult.success();捕获异常之后必须决定恢复、转换、继续处理下一条还是继续抛出。日志只记录发生了什么不会改变程序状态。若无法恢复应让失败沿调用链传递并在服务边界转换成稳定的错误响应。否则数据库可能只写入一半接口却返回成功后续补偿会更困难。异常分为受检异常和非受检异常。受检异常要求调用方显式处理或声明抛出例如常见的 I/O 异常非受检异常通常表示编程错误或违反前置条件也可以用于表达服务层的领域错误。选择哪类异常不应只看“少写几个 throws”要看调用方是否有现实可行的恢复动作。二、在边界处补充上下文保留原始原因底层只知道“第 12 行不能解析”上层知道“正在导入租户 A 的订单文件”。把两层信息连起来比重复打印三次相同堆栈有用得多try{returnparser.parse(line);}catch(IllegalArgumentExceptione){thrownewImportException(第 lineNumber 行格式错误,e);}这里ImportException构造函数应把e作为 cause 传入例如super(message, cause)。若只传e.getMessage()原始堆栈就丢了若到处catch后重新抛出毫无上下文的异常问题定位同样困难。异常消息应包含必要的业务标识、行号或操作名称但不要泄露口令、令牌或完整的敏感数据。还应避免把同一个异常在每一层都记录为错误日志。通常在能够采取行动或即将返回外部响应的边界记录一次其他层只补充上下文并继续传播。重复日志不仅制造噪声还会让故障数量看起来比实际多。三、try-with-resources 管理资源生命周期文件流、数据库连接和某些网络客户端都是资源。只在成功路径关闭资源会留下隐患一旦解析抛异常关闭语句就可能执行不到。try-with-resources会在代码块结束时关闭实现了AutoCloseable的资源importjava.io.BufferedReader;importjava.io.IOException;importjava.nio.charset.StandardCharsets;importjava.nio.file.Files;importjava.nio.file.Path;classLineCounter{staticlongcountNonBlank(Pathpath)throwsIOException{try(BufferedReaderreaderFiles.newBufferedReader(path,StandardCharsets.UTF_8)){longcount0;Stringline;while((linereader.readLine())!null){if(!line.isBlank())count;}returncount;}}}资源的所有权要清楚谁打开通常由谁关闭。方法若接收外部传入的InputStream不能不经约定就关闭它反过来方法内部创建的流也不应随意返回给外部而忘记说明由谁关闭。资源泄漏往往不是因为不知道close()而是因为没有约定生命周期。当try块抛出异常、关闭资源时又抛出异常Java 会保留try中的异常作为主异常把关闭时的异常作为 suppressed exception。可以通过Throwable.getSuppressed()查看。传统finally中直接抛出的关闭异常则可能遮住原始业务失败这也是优先使用 try-with-resources 的重要原因。四、不要捕获过大的范围catch (Exception e)把输入错误、数据库超时、程序中的空指针错误都装进同一个篮子。不同错误应有不同决策格式错误可以报告行号并拒绝文件下游暂时不可用可能允许稍后重试程序错误需要报警和修复。把所有异常转换成“系统繁忙”虽然省事却会让业务方无法判断是否需要修改数据。也不要为了“兜底”捕获Throwable。它还包含某些通常不适合业务代码恢复的严重错误。异常处理边界要尽量窄只包住你确实能解释并处理的操作。正常控制流程也不应依赖异常例如用抛异常代替集合查找失败会让日志、调试和性能分析都变复杂。输入校验最好发生在副作用之前。文件头、字段数量、金额格式和外键约束若能提前检查就能减少“写了一半才发现不合法”的情况。但检查永远无法消除竞态在校验与写入之间数据库状态仍可能变化因此数据库约束和事务仍不可替代。五、批量导入要先定义部分成功策略“1000 行里第 500 行错误”不是纯技术问题。是整体回滚、跳过错误行继续还是每 100 行提交一次三种策略都可能合理但必须由产品和业务契约决定。没有明确策略时异常处理代码就会在多个层之间互相矛盾。整体回滚适合要求数据原子一致的导入。逐行处理适合容忍坏行的数据清洗但应输出成功数、失败数和错误行号并保证重试不会制造重复记录。分批提交能控制事务大小却要求结果报告清楚“前几批已成功、当前批失败”。不要在异常发生后简单地重新运行整个文件除非写入操作具有明确的幂等键。写入数据库时资源关闭与事务提交也不是同一件事。关闭连接不代表业务必然正确提交异常触发回滚的范围必须符合事务管理器的规则。若由框架管理事务应遵循框架约定避免在内层捕获异常后返回正常结果使外层误以为可以提交。六、重试只适用于可恢复、可幂等的失败网络超时可能表示请求未送达也可能表示对方已处理但响应丢失。对订单创建、支付、发券等操作直接重试可能产生重复副作用。先确认是否有幂等键、请求去重、状态查询或补偿方案再设置重试次数和退避时间。相反格式错误、必填字段缺失、业务规则不满足等确定性失败重试同一输入通常不会变好。错误分类应在靠近原因的位置完成但重试决策往往应由掌握业务语义的上层做。底层客户端不应替业务决定“失败三次就算成功”。超时和取消也值得单独对待。当前线程停止等待并不证明下游已经停止执行。返回给用户的“处理中”“失败”“可重试”应与实际系统状态保持一致必要时通过操作 ID 提供结果查询而不是把所有超时都折叠成一个布尔值。七、让异常设计可测试测试至少覆盖成功、输入错误、底层 I/O 失败、关闭失败和部分写入。对异常断言不要只检查类型也要检查 cause 是否保留、错误消息是否包含必要上下文以及外部响应是否泄露内部路径和敏感数据。资源管理测试可以构造一个关闭时抛异常的AutoCloseable验证主异常没有被覆盖。批量导入测试需要覆盖“中间一行失败”的情形检查回滚或部分成功是否与契约一致。实际项目还应验证数据库事务、连接池与框架的行为而不是仅通过单元测试推断整条链路。一次良好的代码审查可以问五个问题这里为何捕获捕获后是否有恢复动作原始原因有没有保留资源由谁关闭调用方能否区分可重试与不可重试答不清楚时增加一个catch通常不是修复而是在隐藏问题。八、建立稳定的异常层次和错误码异常类型最好反映调用方能采取的动作而不是简单对应底层技术名词。可以把导入错误分成三层输入错误例如编码、字段数量和格式不正确业务错误例如订单已存在或状态不允许基础设施错误例如文件系统、数据库和下游服务不可用。上层根据这三类错误分别返回用户可修改、业务可处理或系统可重试的结果。错误码应该稳定异常消息可以更详细。前端或调用方不应解析“订单已经存在”这段自然语言来做分支应得到类似IMPORT_INVALID_ROW、ORDER_ALREADY_EXISTS和DEPENDENCY_TIMEOUT的明确代码。内部日志再包含行号、批次 ID、下游响应和原始 cause。这样既方便国际化也避免改变文案就破坏调用方。不要把数据库唯一键异常直接原样返回用户其中可能包含表名、字段名甚至 SQL 片段。先在靠近领域边界的位置把它转换成业务含义再在系统边界统一序列化。底层异常仍作为 cause 保留供日志和诊断使用。九、日志、敏感数据与错误响应异常日志至少应包含请求 ID、导入批次 ID、文件标识、行号和阶段名称。文件内容、身份证号、令牌、密码和完整支付信息不应为了“方便排查”直接写入日志。需要关联原始记录时可记录脱敏后的业务键或不可逆摘要并限制日志访问权限。同一异常在解析层、服务层和控制器层重复打印会产生三份堆栈却没有三倍信息。建议在能决定返回结果的边界统一记录错误内部层只补充上下文并重新抛出。对于预期的用户输入错误可以用结构化结果而不是错误级别日志避免正常的坏数据把告警系统淹没。对外响应还应防止路径穿越、文件绝对路径和内部类名泄露。生产错误可返回“第 12 行格式错误请下载错误报告”错误报告再通过权限校验提供更细的字段。开发环境可以保留更多诊断信息但不要把开发配置直接带进生产。十、用可恢复设计减少异常压力文件导入可以先把文件登记为一个有状态的任务PENDING、PROCESSING、PARTIAL_SUCCESS、SUCCESS、FAILED。处理过程记录批次 ID、已完成分片和错误报告位置。这样用户遇到超时后可以查询任务状态而不是重新点击并可能重复写入。要实现可恢复写入数据需要幂等键例如“批次 ID 行号”或业务唯一编号。每个分片提交前记录进度重试时跳过已确认成功的部分如果某个分片的提交结果未知先查询写入状态再决定动作。状态机不能只依赖内存变量否则进程重启后会丢失恢复依据。资源关闭、事务提交和任务状态更新要有明确顺序。通常先保证当前事务结果已经确定再记录进度若进度更新失败就需要通过对账任务发现差异。任何“先标记成功、后写数据库”的顺序都可能留下虚假成功除非有额外的可靠消息或补偿机制。十一、异常处理代码审查清单catch是否有真实恢复、转换或补充上下文的目的是否保留了原始 cause而不是只保存字符串资源是否通过 try-with-resources 或等价机制在所有路径关闭事务回滚范围是否覆盖所有相关写入重试操作是否幂等是否设置了次数、退避和总期限日志是否包含定位信息同时避免记录敏感数据用户是否能区分数据错误、业务拒绝、处理中和系统失败当这份清单都能回答清楚时异常处理才真正服务于可恢复性和可运维性。否则更多的try-catch往往只是让错误走得更远却没有让系统更可靠。总结异常是系统对失败的表达资源管理是对生命周期的承诺。让错误在合适边界被解释让原因沿链路保留让资源无论成功失败都被释放再按业务规则决定回滚、跳过或重试导入程序才能在坏数据和故障面前保持可信。参考资料Java 异常教程、AutoCloseable API、Files API。