Understanding Exception Types and @Transactional Usage in Spring

The Alibaba Java coding guidelines require that methods annotated with @Transactional either specify rollbackFor or explicitly handle rollback within the method.

Exception classification : Exceptions are divided into runtime exceptions ( RuntimeException) and non‑runtime (checked) exceptions. Checked exceptions are those that are not subclasses of RuntimeException and must be declared or caught, while unchecked exceptions include RuntimeException and Error.

If a runtime exception is not caught, the thread or the main program will terminate. To prevent termination, all runtime exceptions must be caught; otherwise, an exception in a processing queue could halt subsequent normal processing.

Non‑runtime (checked) exceptions such as IOException, SQLException, or custom exceptions must be caught or declared because the Java compiler enforces this; otherwise the code will not compile.

@Transactional usage : By default, Spring rolls back a transaction only for unchecked exceptions. To roll back for checked exceptions, use @Transactional(rollbackFor=Exception.class). To prevent rollback for unchecked exceptions, use @Transactional(notRollbackFor=RuntimeException.class). For methods that do not require transaction management (e.g., read‑only queries), use @Transactional(propagation=Propagation.NOT_SUPPORTED).

Note : If an exception is caught with try{ }catch{ }, the transaction will not roll back unless the exception is re‑thrown (e.g., throw new Exception()).

Summary : Spring recommends placing @Transactional on concrete classes rather than interfaces, because annotations are not inherited and class‑based proxies will not recognize them on interfaces. Keep transactional methods simple and avoid long‑running or locked operations inside a transaction; perform ordinary read queries outside the transaction and reserve the transaction for create, update, delete, and locked queries.