在Java中如何处理数据库操作异常_Java数据库编程异常处理说明-java教程

必须用 try-catch 处理 SQLException，记录 SQLState、errorCode 和 message；用 try-with-resources 或 finally 逆序关闭资源；按 SQLState 分类处理事务回滚；PreparedStatement 需确认预编译生效防注入。

SQLException 捕获必须用 try-catch，不能只靠 throws

Java 中数据库操作（如 Connection.createStatement()、Statement.executeUpdate()）抛出的是受检异常 SQLException，编译器强制要求处理。只在方法签名加 throws SQLException 是常见偷懒做法，但实际生产中会导致上层调用链处处透传、日志缺失、事务失控。

• 务必用 try-catch 包裹关键 DB 操作，至少记录 e.getSQLState()、e.getErrorCode() 和 e.getMessage()
• 不要只 catch Exception 或 Throwable —— 会掩盖 SQL 特定错误语义（比如唯一约束失败是 23505，外键违例是 23503，PostgreSQL）
• 避免空 catch 块：catch (SQLException e) { } 是线上事故高发源头

连接泄漏比 SQL 错误更隐蔽，必须显式 close

未关闭 Connection、Statement、ResultSet 会导致连接池耗尽、后续请求卡死，这类问题往往在压测或高峰时才暴露，且错误堆栈里不体现“连接已满”，只报超时或 NullPointerException。

• JDBC 4.0+ 支持 try-with-resources，优先用：

  try (Connection conn = dataSource.getConnection();
       PreparedStatement ps = conn.prepareStatement("SELECT * FROM user WHERE id = ?")) {
      ps.setLong(1, userId);
      try (ResultSet rs = ps.executeQuery()) {
          // 处理结果
      }
  }

• 若用旧版 JDK，确保 finally 块中按 ResultSet → Statement → Connection 逆序关闭，且每个 close() 都套 if (x != null) 和独立 try-catch
• Spring 的 JdbcTemplate 或 MyBatis 自动管理资源，但自定义 DataSourceUtils.getConnection() 后仍需手动 release

事务回滚不能只依赖 catch，要检查 SQLState 和 errorCode

不是所有 SQLException 都该回滚。比如查询超时（SQLState = "57014"）可能只需重试，而主键冲突（"23505"）通常应转业务逻辑处理，而非无脑 rollback。

• Spring 声明式事务默认对 RuntimeException 回滚，但 SQLException 是受检异常，需显式配置 @Transactional(rollbackFor = SQLException.class)
• 手动事务中，别写 if (e instanceof SQLException) tx.rollback(); —— 应解析 e.getSQLState() 判断是否属于数据一致性破坏类错误
• HikariCP 等连接池在连接异常中断时可能抛 PooledConnection#checkException，这类底层异常的 SQLState 可能为空，需额外判空

PreparedStatement 预编译失效时，SQL 注入风险仍在

很多人以为用了 PreparedStatement 就绝对安全，但若拼接表名、列名、ORDER BY 字段等非参数化部分，依然可被注入。更隐蔽的是：某些 JDBC 驱动（如旧版 MySQL Connector/J）在 useServerPrepStmts=false 时，实际走字符串拼接，setString() 无效。