https://kotlinlang.org logo
#spring
Title
r

rrader

10/13/2019, 10:07 AM
m

Marko Mitic

10/13/2019, 10:11 AM
Would
@Throws
help?
r

rrader

10/13/2019, 10:36 AM
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
j

jbnizet

10/13/2019, 6:56 PM
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.
👏 1
r

rrader

10/13/2019, 10:18 PM
@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
5 Views