https://kotlinlang.org logo
Join Slack
Powered by
so Spring's @Transactional only triggers when Runt...
# getting-started
b
so Spring's @Transactional only triggers when RuntimeExceptions are thrown; checked exceptions need to be explicitely declared in the annotation itself. How does that interact with Kotlin? Let's say you implement a Java Interface with a checked exception for instance
a
Kotlin does not have any checked exceptions, so it’s not something you’ll discover at compile time. I remember struggling with this in grails/groovy also 🙂
☝️ 1
fwiw, I don’t think the link is 1:1 between RuntimeException/Exception and non-checked/checked? Doesn’t Java have (mostly?) checked RuntimeExceptions, and so those would be caught anyway?
b
right, so my issue is that checked exceptions are kinda lost in kotlin so you must be extra careful to annotate them in @Transactional
a
they’re lost compile time, but the exception itself is still thrown. So the issue will only be with checked exceptions that aren’t subclasses of RuntimeException
b
in Java you can simply infer the exceptions in the method signature that you need to annotate in rollbackFor
exactly
a
that’s only half true, right? You can only infer the checked exceptions, you might get other exceptions
b
and those can ofc be way down in the call stack
a
such as memory allocation issues which throws a Throwable, and isn’t a checked exception
iirc the reasoning for not rolling back on Throwable, is that those exceptions are usually so damning that the entire system has probably shut down, and there’s no reason to try to recover
b
I mean let's say you are calling some java lib method that throws a subclass of Exception in some nested call inside a @Transactional method
a
is that common? Seems to me that libraries throwing non-RuntimeException errors is a bit of an anti-pattern. But yeah, the real world etc, I don’t think you can catch those compile-time in Kotlin at least
b
there's no way to figure what checked exceptions you actually need to account for, if you don't step into your decompiler
yes, checked exceptions in libs are pretty common
a
right - but those checked exceptions are probably mostly/always RuntimeExceptions?
i.e. exceptions that will be caught by 
@Transactional
b
RuntimeExceptions are by default not checked exceptions
a
hmm right, I should probably shut up now, my Java experience is limited
b
tbh I don't know how it's implemented in spring
a
I believe spring just caches all RuntimeException and Error exceptions by default
b
I suppose it just checks if it's a subclass of RuntimeException or Exception
a
right, I believe that’s the case
and you could say 
@Transactional(rollbackFor = Throwable)
if you want
b
correct
just totally caught me off guard and seemed hard to fix with a precise solution
a
pun intended? 🦜
b
😛 anyways, thanks for kinda confirming my suspicions
👍 1
88 Views
Open in Slack
PreviousNext
Powered by