-
Notifications
You must be signed in to change notification settings - Fork 229
fix: handle all exceptions to support Kotlin #2965
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hi @dvob I'm not against this, we probably don't want to change |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we should at least comment on those places that Exception is required because of kotlin
also created a followup issue: #2967 |
Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used. Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry) I will go ahead and add the comments at the places where we catch Exception, ok? |
Yes, pls.
Does not matter; we squash commits. Thank you! |
565ea5a
to
9b0bb8b
Compare
I added the comments and also fixed the typos in the commit message |
...java/io/javaoperatorsdk/operator/processing/dependent/workflow/AbstractWorkflowExecutor.java
Show resolved
Hide resolved
Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.
9b0bb8b
to
49a913e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?
I don't see how it would stop working, could you pls elaborate? |
scratch that, forgot which exception extends which exception |
When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.
The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.
I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.
Maybe there are other places (e.g. OperatorException) which should be changed.