How do you handle this situation <https://github.c...

# spring

[rrader]

How do you handle this situation https://github.com/spring-projects/spring-framework/issues/23789 ?

[Marko Mitic]

Would @Throws help?

[rrader]

Well, it could, at the moment we fixed it as @Transactional(rollbackFor = [Exception::class])
but I think it will be better if this will be handled by Spring by default

[rrader]

https://github.com/spring-projects/spring-framework/issues/23473

[jbnizet]

I don’t understand what the issue is. Spring doesn’t care whether your code was written in Kotlin or in Java. If the transactional method throws an exception whose class is a subclass of RuntimeException, it will rollback. If it doesn’t throw any exception or if it throws an exception that is not a RuntimeException instance, then it will commit. Whether the exception is declared in the throws clause of your method or not doesn’t change anything. So, whether you’re using Kotlin or Java, the strategy is the same: if you want a rollback, you throw an exception which extends RuntimeException, and if you want a commit, you throw an exception that doesn’t extend RuntimeException.

[rrader]

@jbnizet the issue is that in a transactional method we can call a method which can throw IOException, and in this case the transaction will not rollback already mutated data because IOException is not a subclass of RuntimeException