SQLException 是 Java 中必须显式处理的受检异常，专用于数据库错误，携带 getSQLState()、getErrorCode() 等特有诊断信息，区别于可忽略的 RuntimeException。
SQLException 是什么，它和普通 RuntimeException 有什么区别
SQLException 是 Java 中专门用于封装数据库访问错误的受检异常（checked exception），必须显式捕获或声明抛出。它不像 RuntimeException 那样可以忽略处理，不处理会直接编译失败。这意味着只要调用 Connection.createStatement()、PreparedStatement.executeUpdate() 或 ResultSet.next() 等方法，就可能触发它。
它的核心价值在于携带了数据库厂商特有的错误信息：getSQLState()（标准 SQL 状态码）、getErrorCode()（数据库驱动自定义码）、getMessage()（原始错误描述）。这些字段在排查连接超时、主键冲突、锁等待超时等场景时比堆栈更直接。
- PostgreSQL 报错
23505表示唯一约束违反，对应getSQLState()是"23505" - MySQL 的死锁错误通常返回
getErrorCode()为1213，getSQLState()是"40001" - Oracle 的 ORA-00942 对应
getErrorCode()是942，getSQLState()是"42S02"
如何正确捕获并区分不同类型的 SQLException
不能只写一个 catch (SQLException e) 然后统一打印日志——这样会掩盖真实问题。应该根据 getSQLState() 或 getErrorCode() 做分支处理。
注意：不同数据库对 SQLState 的实现程度不一，PostgreSQL 和 HSQLDB 遵循较严格标准，MySQL 驱动（尤其是旧版）常返回空或通用值（如 "HY000"），此时更依赖 getErrorCode()。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 连接失败（如数据库宕机）：检查
e.getSQLState()是否为"08001"或e.getErrorCode()是否为0（MySQL）/-1（HikariCP 包装后） - 事务回滚需求：遇到
"40001"（序列化失败）或"41000"（死锁）应主动connection.rollback() - 数据完整性错误：匹配
"23"开头的SQLState（如"23505"、"23503"），可转为用户友好的提示，而非暴露原始 SQL
try {
ps.executeUpdate();
} catch (SQLException e) {
String sqlState = e.getSQLState();
int errorCode = e.getErrorCode();
if ("23505".equals(sqlState) || errorCode == 1062) { // PostgreSQL / MySQL
throw new BusinessException("用户名已存在");
} else if ("08001".equals(sqlState) || errorCode == 0) {
throw new DataSourceUnavailableException("数据库连接不可用");
} else {
throw e; // 其他未预期错误，原样抛出供上层处理
}
}
为什么 try-with-resources 不能替代 SQLException 处理
try-with-resources 能自动关闭 Connection、Statement、ResultSet，但它完全不干涉异常类型或业务逻辑。如果 close() 过程本身也抛出 SQLException（比如网络中断时释放连接失败），它会被压制（suppressed），除非你显式调用 e.getSuppressed() 查看。
更关键的是：资源关闭成功 ≠ SQL 执行成功。一个 INSERT 已执行但未提交，随后连接被 close，事务就丢了——这属于业务逻辑缺陷，不是资源管理问题。
- 不要在
try-with-resources的catch块里只记录日志就完事，要判断是否需要重试或补偿 - 涉及事务的代码，
commit()和rollback()必须放在finally或单独try-catch中，不能依赖close() - 使用连接池（如 HikariCP）时，
close()实际是归还连接，不会真正断开，但依然可能抛出SQLException（如连接已被标记为废弃）
PreparedStatement.executeBatch() 抛出 SQLException 怎么定位具体哪条失败
executeBatch() 返回的是 int[]，其中 Statement.EXECUTE_FAILED（值为 -3）表示某条语句执行失败，但不会告诉你失败原因。此时必须调用 getUpdateCounts() 并结合 getSQLException()（部分驱动支持）或启用批处理异常报告。
MySQL 驱动需在 JDBC URL 中添加 continueBatchOnError=false（默认为 true），否则一条失败会跳过后续语句，且不抛异常；PostgreSQL 驱动则默认逐条执行，失败即停。
- 批量插入 100 条，返回
int[100]，第 5 个元素是-3→ 第 5 条 SQL 出错 - HikariCP + MySQL 场景下，若未设
continueBatchOnError=false，可能整个 batch 返回[1,1,1,-3,1,...]，但实际只有前 3 条生效 - 更稳妥做法：对关键批量操作，改用单条
executeUpdate()加手动事务控制，便于精准捕获每条的SQLException
真正难处理的，是那种没有明确行号、getSQLState() 又是通用码（如 "HY000"）的批处理失败——这时候只能靠日志关联 SQL 模板与参数，再人工比对。
