看起来api没有定义任何特定的异常处理机制。i、 未捕获的异常只是通过线程帧弹出，并最终被记录到stderr。
我发现您可以利用以下异常处理策略：
在任务类中定义提交给线程池的对象的处理程序；
为线程池提供自己的threadfactory实现，该线程池通过setuncaughtexceptionhandler（）或threadgroup的uncaughtexception（）初始化默认处理程序；

如果您正在使用 scheduleAtFixedRate() 或者 scheduleAtFixedDelay() ，并且您的任务退出，但有一个例外，该任务将不会被重新安排。但是，其他独立任务应继续按预期执行(参见api文档）。如果你关心这件事的发生，你可以抓住 ScheduledFuture 返回并调用 get() 方法。如果底层任务抛出异常，您将从 get() 方法， Package 在 ExecutionException .

两者的javadoc scheduleAtFixedRate 以及 scheduleWithFixedDelay 说“如果任务的任何执行遇到异常，后续的执行将被抑制。”我不认为这是非常清楚的，但似乎是说如果 run 方法抛出任何类型的异常，那么调度器将有效地丢弃该任务。通过该调度器运行的任何其他任务都不应受到影响。测试它的实际功能应该不难。。。
取消任务未必是坏事。如果run方法抛出 RuntimeException ，可能是某个地方有个bug，系统状态未知。但至少我建议 RuntimeException 在run方法中，并在severe中记录完整的堆栈跟踪。根据具体情况，您可能需要重新触发以取消任务。但是无论哪种方式，你都需要日志记录来有机会找出哪里出了问题。

这个人也有同样的问题。
http://code.nomad-labs.com/2011/12/09/mother-fk-the-scheduledexecutorservice/
他的解决办法是抓住 Exception 在runnable内部重新抛出 RuntimeException :

try {
       theRunnable.run();
    } catch (Exception e) {
       // LOG IT HERE!!!
       System.err.println("error in executing: " + theRunnable + ". It will no longer be run!");
       e.printStackTrace();

       // and re throw it so that the Executor also gets this error so that it can do what it would
       // usually do
       throw new RuntimeException(e);
}