Java数据库异常处理与错误解析指南

Java数据库异常处理的核心在于避免直接暴露底层SQLException，而应通过自定义异常封装或Spring的DataAccessException体系进行语义化、标准化转化；借助SQLExceptionTranslator统一映射错误类型（如DuplicateKeyException、DataIntegrityViolationException），并精准提取SQLState、errorCode等字段实现可维护的错误判别逻辑，同时警惕连接池异常、事务回滚配置遗漏及网络闪断导致的半开连接陷阱——这不仅保障分层架构的清晰性与稳定性，更让数据访问错误真正变得可观测、可重试、可治理。

Java中SQLException该不该直接抛出

不应该。直接抛出 SQLException 会把数据库驱动细节（比如 MySQL 的 CommunicationsException、Oracle 的 SQLRecoverableException）暴露到业务层，破坏分层隔离，也导致上层无法区分是连接失败、超时还是语法错误。

典型错误写法：

public User findById(int id) throws SQLException {
    String sql = "SELECT * FROM user WHERE id = ?";
    try (PreparedStatement ps = conn.prepareStatement(sql)) {
        ps.setInt(1, id);
        ResultSet rs = ps.executeQuery();
        // ...
    }
}

正确做法是捕获后转为自定义异常或 Spring 的 DataAccessException 子类。JDBC 规范本身不强制要求统一异常类型，各驱动实现差异大，必须封装。

Spring JDBC 中如何统一处理 SQL 异常

依赖 Spring 的 org.springframework.dao 异常体系，它通过 SQLExceptionTranslator 将原生 SQLException 映射为语义明确的运行时异常，如：

• DuplicateKeyException → 主键/唯一约束冲突
• DataIntegrityViolationException → 外键、非空、检查约束失败
• CannotAcquireLockException → 行锁等待超时（MySQL 的 LockWaitTimeoutException）
• UncategorizedSQLException → 未被映射的底层错误，需查 getRootCause()

使用要点：

• 确保配置了 DataSource 和 JdbcTemplate，Spring 会自动注册默认 translator
• 若用 MyBatis，需启用 spring.datasource.hikari.data-source-properties.useSSL=false 类似参数避免 SSL 相关异常被误判
• 自定义 translator 需继承 SQLStateSQLExceptionTranslator 或 SQLExceptionTranslator 接口

手动封装 SQLException 的关键字段提取

当不用 Spring，或需在 DAO 层做精细控制时，应从 SQLException 中提取三个核心字段判断问题类型：

• getSQLState()：标准 SQL 状态码（如 "23000" 表示完整性约束违规）
• getErrorCode()：数据库厂商专属码（MySQL 是纯数字，如 1062；PostgreSQL 是五位字符串）
• getLocalizedMessage()：带上下文的提示，但不可用于逻辑分支判断（内容不稳定）

示例判断逻辑：

if ("23000".equals(ex.getSQLState()) || ex.getErrorCode() == 1062) {
    throw new UserAlreadyExistsException("用户名已存在");
} else if (ex.getErrorCode() == 1205) { // MySQL deadlock
    throw new RetryableDataAccessException("死锁，请重试", ex);
}

注意：不要只依赖 getMessage() 做匹配，不同驱动版本返回消息格式可能变化。

连接池异常和事务回滚的常见误判点

HikariCP、Druid 等连接池抛出的异常往往不是 SQLException，而是包装后的运行时异常，容易漏处理：

• HikariPool$PoolInitializationException：数据源初始化失败（URL 错、权限不足）
• SQLTimeoutException：查询超时，但它是 SQLException 子类，可被 translator 捕获
• TransactionSystemException：Spring 事务管理器包装的底层异常，需调用 getCause().getCause() 才能拿到原始 SQLException

事务中发生异常时，仅捕获 SQLException 不够——必须确认是否已触发回滚。Spring 默认只对 RuntimeException 回滚，而 SQLException 是检查异常，若未声明 @Transactional(rollbackFor = SQLException.class)，事务不会回滚。

真正难缠的是网络闪断导致的半开连接：连接池可能返回一个已失效的 Connection，首次执行时才抛 CommunicationsException，此时事务早已开始，需靠连接池的 connection-test-query 或 validation-timeout 提前探测。

以上就是《Java数据库异常处理与错误解析指南》的详细内容，更多关于的资料请关注golang学习网公众号！