SQLException 是 checked exception，因数据库操作天然不可靠，JDBC 规范强制处理以避免静默失败；它不自动触发回滚，需显式调用 rollback() 或配置 Spring 的 rollbackFor。
SQLException 是检查异常，不是设计失误，而是 JDBC 为强制你面对数据库不确定性而设的“安全锁”。
为什么 SQLException 必须是 checked exception？
Java 异常体系里，
继承自
而非
，意味着编译器强制你处理它——要么
，要么
。这不是历史包袱甩不掉，而是 JDBC 规范（JSR-114）早期就定下的契约：数据库操作天然不可靠（网络中断、死锁、权限不足、约束冲突……），不能让你“假装没发生”。
比如执行一条
，可能因主键重复抛出
，也可能因连接断开抛出
，这两类错误的应对策略完全不同：前者要提示用户改数据，后者要重试或降级。强制声明，就是逼你在代码路径里显式分叉。
不处理
→ 编译失败 → 避免上线后因未捕获连接异常导致服务静默失败
Spring 默认不回滚
→ 正是因为它是 checked exception，框架假设你会自己判断并决策（重试？告警？回滚？）
如果它是 runtime exception，大量 DAO 方法会“侥幸”不加保护，事务一致性立刻失控
SQLException 和事务回滚之间没有自动绑定关系
很多人以为“抛了
就等于事务回滚了”，这是最危险的误解。JDBC 层面，
只是通知你出错了；是否回滚，完全取决于你有没有在
块里调用
，且该
当前处于 active transaction 状态。
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
立即学习
“
Java免费学习笔记（深入）
”；
默认
：每条 SQL 单独提交，
抛出时前一条已落库，回滚无意义
手动关了
却忘了
→ 数据库卡在中间状态，连接池可能回收连接但事务未清理 → 后续报
Spring 中加了
但没写
→
被 catch 吞掉或仅 log，事务照常提交
真实项目里怎么接住 SQLException 并合理回滚？
别只写
，那等于把日志当摆设。关键是要从异常里榨出可操作信息，并匹配动作：
先看
：
（连接中断）、
（死锁）→ 可重试；
（唯一冲突）、
（语法错）→ 不该重试，应业务拦截
再查
：MySQL 的
、PostgreSQL 的
，比 SQLState 更准，适配具体数据库行为
记录完整上下文：SQL 原文 + 参数列表 +
+
，否则排查时只能猜
回滚前必判状态：
，避免调用
报
真正难的不是写 try-catch，是在分布式、连接池、Spring 代理、多数据源混用的场景下，搞清“此刻事务归谁管、能不能滚、滚了有没有效”。一个
抛出来，背后可能是网络层断连、数据库锁表、连接池超时、Spring 事务传播失效……它从来不只是个异常，而是一张问题定位地图的起点。
SQLExceptionExceptionRuntimeExceptiontry-catchthrowsINSERTSQLState="23000"SQLState="08S01"SQLExceptionSQLExceptionSQLExceptionSQLExceptioncatchconnection.rollback()ConnectionautoCommit = trueSQLExceptionautoCommitrollback()"The transaction is no longer active - status: 'Marked rollback'"@TransactionalrollbackFor = SQLException.classSQLExceptione.printStackTrace()e.getSQLState()"08S01""40001""23000""42000"e.getErrorCode()120540001getSQLState()getErrorCode()if (!conn.isClosed() && !conn.getAutoCommit()) { conn.rollback(); }rollback()"No transaction in progress"SQLException