应将try-catch置于循环体内实现单行隔离，捕获具体异常并记录行号、字段名、原始值等上下文，配合try-with-resources确保资源安全，避免大try包整个循环。
在数据导入场景中，比如批量解析 CSV、读取数据库结果集或调用外部接口拉取记录，单条数据出错（如格式错误、空字段、类型转换失败）很常见。目标不是让整个导入中断，而是跳过坏数据、记录问题、继续处理后续有效数据。关键在于“单行隔离”和“错误不传播”。
把 try-catch 放进循环体内部
这是最直接有效的做法。每次迭代处理一条数据时，都用独立的 try-catch 包裹核心逻辑，确保异常被限制在当前行范围内。
- 异常发生在某次迭代 → 进入该次的 catch → 执行完后自动进入下一次 for/while 循环
- 不需要写 continue（除非你想跳过后续校验或日志之外的逻辑）
- 错误不会影响循环变量、计数器或条件判断
捕获具体异常并记录上下文
空 catch 或只打印 e.printStackTrace() 不利于排查。应针对常见问题分类处理，并带上关键定位信息：
- 对 NumberFormatException：记录原始字符串值、字段名、行号
- 对 NullPointerException：检查是否必填字段为空，输出缺失字段名
- 对 DateTimeParseException：附上待解析的时间字符串和期望格式
- 建议统一记录：文件名 / 接口地址 / 行索引 / 原始数据片段
配合轻量降级与资源安全
导入过程常涉及流、连接等资源，不能因某行异常导致泄漏：
立即学习“Java免费学习笔记（深入）”；
- 用 try-with-resources 管理 InputStream、BufferedReader、ResultSet 等，即使某行抛异常，资源仍自动关闭
- 对无效数据可填充默认值（如 status=0）、标记为“待人工复核”，而非直接丢弃
- 避免在 catch 中重试或递归调用——容易引发栈溢出或无限循环
不推荐：用一个大 try 包住整个循环
这种写法看似省事，但实际违背导入需求：
- 一旦第 5 行出错，第 6 行及之后全部跳过，导入中途终止
- 无法统计成功/失败条数，也无法定位是哪一行、什么原因失败
- 只适合“全有或全无”的强一致性操作（如事务初始化），不适合容忍局部失败的 ETL 场景
