不该直接抛出SQLException。应捕获后转为自定义异常或Spring的DataAccessException子类，通过SQLExceptionTranslator统一映射为语义明确的运行时异常，并提取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 映射为语义明确的运行时异常，如：
立即学习“Java免费学习笔记（深入）”；
-
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 提前探测。
