ScheduledExecutorService Exception handling

by

tl;dr

Any exception escaping your run method halts all further work, without notice.

Always use a try-catch within your run method. Try to recover if you want scheduled activity to continue.

@Override
public void run ()
{
    try {
        doChore();
    } catch ( Exception e ) { 
        logger.error( "Caught exception in ScheduledExecutorService. StackTrace:\n" + t.getStackTrace() );
    }
}

The Problem

The question refers to the critical trick with a ScheduledExecutorService: Any thrown exception or error reaching the executor causes the executor to halt. No more invocations on the Runnable, no more work done. This work stoppage happens silently, you’ll not be informed. This naughty-language blog posting entertainingly narrates the hard way to learn about this behavior.

The Solution

The answer by yegor256 and the answer by arun_suresh both seem to be basically correct. Two issues with those answers:

  • Catch errors as well as exceptions
  • A bit complicated

Errors and Exceptions ?

In Java we normally catch only exceptions, not errors. But in this special case of ScheduledExecutorService, failing to catch either will mean a work stoppage. So you may want to catch both. I’m not 100% sure about this, not knowing fully the implications of catching all errors. Please correct me if needed.

One reason to catch errors as well as exceptions might involve the use of libraries within your task. See the comment by jannis.

One way to catch both exceptions and errors is to catch their superclass, Throwable for an example.

} catch ( Throwable t ) {

…rather than…

} catch ( Exception e ) {

Simplest Approach: Just Add a Try-Catch

But both answers are a bit complicated. Just for the record, I’ll show the simplest solution:

Always wrap your Runnable’s code in a Try-Catch to catch any and all exceptions and errors.

Lambda Syntax

With a lambda (in Java 8 and later).

final Runnable someChoreRunnable = () -> {
    try {
        doChore();
    } catch ( Throwable t ) {  // Catch Throwable rather than Exception (a subclass).
        logger.error( "Caught exception in ScheduledExecutorService. StackTrace:\n" + t.getStackTrace() );
    }
};

Old-Fashioned Syntax

The old-fashioned way, before lambdas.

final Runnable someChoreRunnable = new Runnable()
{
    @Override
    public void run ()
    {
        try {
            doChore();
        } catch ( Throwable t ) {  // Catch Throwable rather than Exception (a subclass).
            logger.error( "Caught exception in ScheduledExecutorService. StackTrace:\n" + t.getStackTrace() );
        }
    }
};

In Every Runnable/Callable

Regardless of a ScheduledExecutorService, it seems sensible to me to always use a general try-catch( Exception† e ) in any run method of a Runnable. Ditto for any call method of a Callable.

Complete example code

In real work, I would likely define the Runnable separately rather than nested. But this makes for neat all-in-one example.

package com.basilbourque.example;

import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledFuture;
import java.util.concurrent.TimeUnit;

/**
 *  Demo `ScheduledExecutorService`
 */
public class App {
    public static void main ( String[] args ) {
        App app = new App();
        app.doIt();
    }

    private void doIt () {

        // Demonstrate a working scheduled executor service.
        // Run, and watch the console for 20 seconds.
        System.out.println( "BASIL - Start." );

        ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
        ScheduledFuture < ? > handle =
                scheduler.scheduleWithFixedDelay( new Runnable() {
                    public void run () {
                        try {
                            // doChore ;   // Do business logic.
                            System.out.println( "Now: " + ZonedDateTime.now( ZoneId.systemDefault() ) );  // Report current moment.
                        } catch ( Exception e ) {
                            // … handle exception/error. Trap any unexpected exception here rather to stop it reaching and shutting-down the scheduled executor service.
                            // logger.error( "Caught exception in ScheduledExecutorService. StackTrace:\n" + e.getStackTrace() );
                        }   // End of try-catch.
                    }   // End of `run` method.
                } , 0 , 2 , TimeUnit.SECONDS );


        // Wait a long moment, for background thread to do some work.
        try {
            Thread.sleep( TimeUnit.SECONDS.toMillis( 20 ) );
        } catch ( InterruptedException e ) {
            e.printStackTrace();
        }

        // Time is up. Kill the executor service and its thread pool.
        scheduler.shutdown();

        System.out.println( "BASIL - Done." );

    }
}

When run.

BASIL – Start.

Now: 2018-04-10T16:46:01.423286-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:03.449178-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:05.450107-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:07.450586-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:09.456076-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:11.456872-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:13.461944-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:15.463837-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:17.469218-07:00[America/Los_Angeles]

Now: 2018-04-10T16:46:19.473935-07:00[America/Los_Angeles]

BASIL – Done.

Another example

Here is another example. Here our task is meant to run about twenty times, once every five seconds for a minute. But on the fifth run, we throw an exception.

public class App2
{
    public static void main ( String[] args )
    {
        ScheduledExecutorService ses = Executors.newSingleThreadScheduledExecutor();
        final AtomicInteger counter = new AtomicInteger( 0 );
        Runnable task = ( ) -> {
            int c = counter.incrementAndGet();
            if ( c > 4 )
            {
                System.out.println( "THROWING EXCEPTION at " + Instant.now() );
                throw new IllegalStateException( "Bogus exception. c = " + c + ". " + Instant.now() ); // Notice how this exception is silently swallowed by the scheduled executor service, while causing a work stoppage.
            }
            System.out.println( "Task running. c = " + c + ". " + Instant.now() );
        };
        ses.scheduleAtFixedRate( task , 0 , 5 , TimeUnit.SECONDS );

        try { Thread.sleep( Duration.ofMinutes( 1 ).toMillis() ); }catch ( InterruptedException e ) { e.printStackTrace(); }
        System.out.println( "Main thread done sleeping. " + Instant.now() );

        ses.shutdown();
        try { ses.awaitTermination( 1 , TimeUnit.MINUTES ); }catch ( InterruptedException e ) { e.printStackTrace(); }
    }
}

When run.

Task running. c = 1. 2021-10-14T20:09:16.317995Z
Task running. c = 2. 2021-10-14T20:09:21.321536Z
Task running. c = 3. 2021-10-14T20:09:26.318642Z
Task running. c = 4. 2021-10-14T20:09:31.318320Z
THROWING EXCEPTION at 2021-10-14T20:09:36.321458Z
Main thread done sleeping. 2021-10-14T20:10:16.320430Z

Notice:

  • The exception is silently swallowed by the scheduled executor service.
  • A work stoppage occurs. No further executions of our task are scheduled. Again, a silent problem.

So when your task throws an exception, you get the worst outcome possible: Silent work stoppage with no explanation.

The solution, as mentioned above: Always use a try-catch within your run method.

† Or perhaps Throwable instead of Exception to catch Error objects too.

More Related Contents:

  1. Java thread affinity
  2. How to properly stop the Thread in Java?
  3. Why is spawning threads in Java EE container discouraged?
  4. Why must wait() always be in synchronized block
  5. Volatile vs Static in Java
  6. How can I pass a parameter to a Java Thread?
  7. Choose between ExecutorService’s submit and ExecutorService’s execute
  8. Updating UI from different threads in JavaFX
  9. How to demonstrate java multithreading visibility problems?
  10. java.lang.IllegalMonitorStateException: object not locked by thread before wait()?
  11. What are the main uses of yield(), and how does it differ from join() and interrupt()?
  12. What is the JVM thread scheduling algorithm?
  13. Why does Thread.isInterrupted () always return false?
  14. How does `this` reference to an outer class escape through publishing inner class instance?
  15. Why we call Thread.start() method which in turns calls run method?
  16. When does a Java Thread reach the ‘Die’ State
  17. How does the event dispatch thread work?
  18. Which concurrent Queue implementation should I use in Java?
  19. How to abort a thread in a fast and clean way in java?
  20. AsyncTask.executeOnExecutor() before API Level 11
  21. Jboss Java EE container and an ExecutorService
  22. Why is there no GIL in the Java Virtual Machine? Why does Python need one so bad?
  23. How does the JVM terminate daemon threads? or How to write daemon threads that terminate gracefully
  24. java timer task schedule
  25. Run Handler messages in a background thread
  26. Regarding thread safety of servlet [duplicate]
  27. who and when notify the thread.wait() when thread.join() is called?
  28. notifyAll() throws IllegalMonitorStateException
  29. Will a chain of method calls (CompletableFuture API) execute asynchronously if the first method in a chain is asynchronous?
  30. Concurrent read/write of named pipe in Java (on windows)

Leave a Comment