Add guidelines about using checked exception with proxies in Kotlin

[masc3d]

Im seeing UndeclaredThrowableException for kt methods which are invoked through spring proxy (eg. when using @Transactional)

it can be mitigated by explicit @Throws(Throwable::class)
The issue does not occur for RuntimeExceptions

example: https://github.com/masc3d/spring-kotlin-jpa

[sdeleuze]

This behavior happens when the method is throwing a checked exception, like with TimeoutException in your repro project. This seems to be a known behavior described for example in https://stackoverflow.com/a/44790753/1092077.

I see the following stacktrace when that happens:

java.lang.reflect.UndeclaredThrowableException
	at com.sun.proxy.$Proxy128.updateCity(Unknown Source)
	at de.rpr.mycity.domain.city.JpaCityServiceTest.'updateCity' should update existing values(JpaCityServiceTest.kt:104)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	...
Caused by: java.util.concurrent.TimeoutException
	at de.rpr.mycity.domain.city.JpaCityService.updateCity(JpaCityService.kt:33)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:294)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:98)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)

@jhoeller Do you think we can/should do something here like making the proxy aware that Kotlin methods can potentially throws Exception? If we can't do anything, I will turn this issue as a documentation one.

[sdeleuze]

This dedicated blog post gives some interesting insights and seems to confirm we can't do anything about that except documenting it.

[masc3d]

This dedicated blog post gives some interesting insights and seems to confirm we can't do anything about that except documenting it.

it actually confirms that it could be addressed, technically.
which doesn't necessarily mean it's a good idea of course.

[masc3d]

imho if spring actively supports kt it should be addressed.

[sdeleuze]

After discussing with @jhoeller, testing also with CGLIB proxies and trying to unwrap the exception in ReflectiveMethodInvocation, I still see this UndeclaredThrowableException. And I don't think the proposed ways of fixing that in the blog post are doable or at least not something I find reasonable to implement in Spring Framework.

So I will turn this issue into a documentation one, and advise people that are using proxies and checked exceptions to declare them via @Throws, that seems reasonable from my POV.

[masc3d]

wouldn't it be possible to add annotations at runtime for affected kt methods?

[masc3d]

exception handling of each and every method that's called via proxy being potentially defective due to forgetting @Throws doesn't actually sound reasonable to me.

[sdeleuze]

If I am not mistaken, @Throws modifies how Kotlin compiler generates bytecode, I don't see how we could do something about it at runtime. If implemented, I tend to think that feature should live in the kotlin-spring compiler plugin. If you care, I would suggest you to create an issue about that on https://youtrack.jetbrains.com/issues/KT.