应将try-catch置于循环体内而非包裹整个循环，确保单次异常不中断整体执行；需配合日志、分类处理、资源安全释放（如try-with-resources）以提升健壮性。
关键在于把 try-catch 放进循环体内部，而不是包住整个循环。这样某次迭代出错，只影响当前轮次，其余迭代照常执行。
循环体内嵌 try-catch 是标准做法
这是实现“单次失败、整体继续”的最直接方式。异常被限制在当前 iteration 范围内处理，不会打断循环计数或条件判断。
- 每次迭代开始前，都有一套独立的 try-catch 作用域
- 异常发生在 try 块中 → 进入对应 catch → 执行完 catch 后自动进入下一次迭代
- 无需显式写
continue（除非你想跳过后续逻辑）
避免把整个循环包在 try-catch 里
如果写成 try { for (...) { ... } }，一旦某次迭代抛异常，循环立刻终止，后续元素完全不处理——这和没加异常处理基本一样。
- 这种结构适合“全有或全无”的场景，比如初始化一组强依赖资源
- 但不适合批量解析、文件读取、接口调用等容忍局部失败的场景
配合日志与轻量降级提升健壮性
捕获后不能只是空 catch，否则问题难以定位。建议记录关键上下文，并明确是否跳过、填充默认值或走备用逻辑。
立即学习“Java免费学习笔记（深入）”；
- 打印出错的原始数据（如当前字符串、索引、文件名）
- 对 NumberFormatException、NullPointerException 等常见异常做分类处理
- 必要时用
continue显式跳过无效项，避免后续空指针
注意资源管理不因异常被忽略
如果循环中打开文件、数据库连接或流对象，别只靠 try-catch，要用 try-with-resources 或 finally 确保释放。
- 资源泄漏风险比单次异常更严重
- 例如遍历多个文件时，某个文件打不开，仍要保证之前打开的流被关闭
- 推荐：把资源获取和操作封装进独立方法，内部用 try-with-resources
