java中处理sqlexception需精准捕获、记录sql语句与参数、获取sqlstate/errorcode诊断信息，强制使用try-with-resources释放资源，按sqlstate分类差异化处理（如08s01重试、23505转业务提示），并在dao层封装为自定义异常向上抛出。
Java中处理SQLException不能只靠try-catch包住就完事，关键在于捕获后要能定位问题、释放资源、区分错误类型，并让上层有明确的响应路径。
捕获时必须记录核心诊断信息
只写catch (SQLException e) { e.printStackTrace(); }会丢失调试必需上下文。每次捕获都应至少记录：
- 原始SQL语句（特别是动态拼接或带占位符的）
-
绑定参数值（如
id=123, status='ACTIVE'） -
e.getSQLState()（标准五位码，如
"23505"表示唯一约束冲突） -
e.getErrorCode()（厂商专属码，如MySQL的
1062、PostgreSQL的23505） - e.getMessage()（辅助理解，但不可用于逻辑判断）
资源释放必须用try-with-resources
Connection、PreparedStatement、ResultSet都实现了AutoCloseable，手动close容易遗漏或出错。正确写法是：
✅ 推荐：
try (Connection conn = dataSource.getConnection();<br>
PreparedStatement ps = conn.prepareStatement("UPDATE user SET name = ? WHERE id = ?");<br>
ResultSet rs = ps.executeQuery()) {<br>
// 执行逻辑<br>
} catch (SQLException e) {<br>
// 处理异常<br>
}
❌ 避免：在finally里逐个close，或复用同一个Statement执行多个查询导致ResultSet提前关闭。
按SQLState精准分类，不做一刀切处理
不同SQLState代表完全不同的问题性质，处理策略应差异明显：
- "08S01"（连接中断）→ 可重试，配合指数退避
- "40001"（死锁）→ 回滚后重试，不延长事务
- "23505"（唯一约束冲突）→ 属业务正常分支，转为用户提示或降级逻辑
- "42S02"（表不存在）→ 属部署或配置问题，需告警而非重试
- "23503"（外键违例）→ 检查数据一致性，非瞬时故障
切忌用getMessage().contains("Duplicate")做判断——语言、版本、字段名变化都会导致匹配失效。
分层转化异常，屏蔽JDBC细节
DAO层不应把SQLException直接抛给Service。正确做法是：
- 在DAO内捕获SQLException
- 根据SQLState和业务语义，包装为自定义异常（如
DuplicateKeyException、DeadlockException） - 保留原始SQLException作为cause，便于追溯根因
- Service层只感知业务异常，无需了解JDBC或数据库厂商细节
例如：throw new UserAlreadyExistsException("User email already registered", e);
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
