Not stopping execution after exception in Scheduled Tasks


I have a scheduled task that perform some web API calls through a service. Executing this service can throw exceptions, for example in case of 400 responses from the third party API. Even though I put my code inside try catch blocks, the code inside the catch is never executed and the real exception is never caught, but instead the ServiceInterceptor picks them up and cancels the execution of the task.

Any way to bypass this functionality?

If the exception class is defined in your code, you can mark it with the @SupportedByClient annotation: Passing Middleware Exceptions - CUBA Platform. Developer’s Manual

Otherwise, the only choice is to create a Spring Bean in the core module, additionally to middleware service, and extract the logic to the bean. Only middleware service calls are wrapped by the ServiceInterceptor. The service can still be called from the UI, it just has to delegate the operations to the Spring Bean.

The exception is already marked with the SupportedByClient annotation yet it doesnt work. Just to clarify the architecture:

public class MyScheduledTask {
    private MyWebAPIService apiService;

    // This is the method that is invoked by the scheduled task
    public void go() {
        for (MyEntity x : entities) {
            try {
            } catch (MyException e) {
                // This block is never reached, because as soon as the 
                // exception is thrown the execution is stopped     

So MyWebAPIService.update throws MyException and MyScheduledTask is used for one cuba.core.ScheduledTask where I would like to be able to keep going even when exceptions are thrown. Note that MyException is marked with SupportedByClient

I’m sorry, I don’t understand what is “execution is stopped”. There is no such thing in Java.

You can change the code to catch any exception, and find out which exception class is reaching the go() method.
Or change the logic to use Spring Bean.
Middleware services are a bridge between web layer and core. When the logic is in the core module, it makes perfect sense to use Spring Beans instead.