Let's look at all the places where we call methods of ScheduledExecutorService (one of such places is us calling schedule in NettyStream), and do not handle the exceptions from the returned Future​s;

1. If easily doable, we should handle the exceptions from those Future​s. But I suspect, in most if not all cases it is not really doable.
2. If not, we should make sure that the Runnable/Callable​s objects we schedule catch everything, log Exception​s they can't really handle, and handle all Error​s by calling Thread.currentThread().getThreadGroup().uncaughtException(e, Thread.currentThread()) (if we throw them, they are caught by the executor, and not propagated as uncaught exceptions).
   1. Instead of modifying every Runnable/Callable we schedule, we can achieve this by extending ScheduledThreadPoolExecutor that we use and overriding its afterExecute method (the documentation of the method should be carefully read and followed). Such an approach can also failproof future code, provided that we forbid explicit usage of ScheduledThreadPoolExecutor/Executors. ...scheduled.../ForkJoinPool.schedule... via a static checker.

This combined with JAVA-5907 (we replaced submit invocations with execute), JAVA-6110 ensures that the default uncaught exception handler configured by an application will have a chance to handle all Errors that originate from our code. And if there no uncaught exception handler is configured, the Error​s at least will be handled the same way the Java SE handles all uncaught exceptions by default.

This ticket was created based on this PR comment.