Understanding Exception Types and @Transactional Usage in Spring

Hello, I am a top architect.

1. Classification of Exceptions

Java's Alibaba coding guidelines require that methods annotated with @Transactional specify rollbackFor or handle rollbacks explicitly.

Exceptions are divided into two main categories: RuntimeException (unchecked) and non‑runtime (checked) exceptions. Errors always trigger a rollback.

Checked exceptions are those that extend Exception but are not subclasses of RuntimeException. Unchecked exceptions include RuntimeException and its subclasses, as well as Error.

If unchecked exceptions are not handled, they may cause the main program to terminate; to prevent termination, all unchecked exceptions must be caught, logged, and the processing of normal data should continue without being affected by the exception data.

Because the Java compiler forces handling of checked exceptions, developers often end up writing many try { … } catch (…) { … } blocks.

2. Writing @Transactional

When using @Transactional without additional attributes, only unchecked exceptions (e.g., RuntimeException) and Error trigger a transaction rollback.

1) To make checked exceptions roll back, add @Transactional(rollbackFor = Exception.class) to the method.

2) To prevent unchecked exceptions from rolling back, use @Transactional(notRollbackFor = RuntimeException.class).

3) For methods that do not require transaction management (read‑only queries), set propagation to @Transactional(propagation = Propagation.NOT_SUPPORTED).

Note: If an exception is caught and not re‑thrown, the transaction will not roll back; you must re‑throw the exception after catching it if you want a rollback.

Spring recommends placing @Transactional on concrete classes or methods rather than on interfaces, because annotations on interfaces are not inherited by class‑based proxies.

Transactional methods should be kept simple; avoid putting non‑transactional logic inside them, and perform read‑only queries before the transaction starts, reserving the transaction for write, delete, update, and locked queries.