I couldn’t understand even after reading the java docs. When is this preferred over throw any RuntimeException instead?
1 Like
The only use is to throw a checked exception without specifying it in the method signature (which is not allowed for workflow and activity functions). The alternative of wrapping it in your own RuntimeException also works but creates unnecessary noise in the resulting stack traces.
Can you expand on what you mean that throwing checked exceptions is not allowed in ActivityMethod signatures? I also see it mentioned in the java sdk documentation, but fail to understand the rationale.
I also tested my ActivityMethod throwing a checked exception and wrapping it, and the behavior, performance, retry logic, and logging all seemed equivalent.
An activity invocation through its stub throws only ActivityFailure exception. So if an activity implementation throws something like IOException the workflow is going receive an ActivityFailure with an ApplicationFailure that contains the IOException information chained to it.
So using a checked exception in an activity function signature would be very misleading to the caller which would be forced to handle an exception that is never thrown from the method.
1 Like