Java中的SQLException异常与数据库操作-java教程-PHP中文网

SQLException 是 Java 中必须显式处理的受检异常，专用于数据库错误，携带 getSQLState()、getErrorCode() 等特有诊断信息，区别于可忽略的 RuntimeException。

java中的sqlexception异常与数据库操作

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()。

连接失败（如数据库宕机）：检查 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() 查看。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

更关键的是：资源关闭成功 ≠ 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 模板与参数，再人工比对。