ScheduledExecutorService throwable lost

Рассмотрите, что я запланировал Runnable для периодического выполнения с помощью ScheduledExecutorService и возникает некоторая системная ошибка, например OutOfMemory. Он будет молча проглочен.ScheduledExecutorService throwable lost

scheduler.scheduleWithFixedDelay(new Runnable() { 
        @Override 
        public void run() { 
         throw new OutOfMemoryError(); // Swallowed 
        } 
       }, 0, delay, TimeUnit.SECONDS);

Нормально ли это?

Почему он не распространяется на контейнер?

Каков правильный способ обработки таких ошибок?

Спасибо!

источник

2011-01-12 Andrey Minogin

OutOfMemoryError, как и любой подтип Error, не могут быть восстановлены, они, как правило, являются фатальными для вашей программы. Не имеет значения, пытаетесь ли вы его поймать или нет, ваша программа идет вниз.

Если, однако, вы имеете в виду в Exception, а не Error, то у вас есть 2 варианта:

поймать исключение из run() в методе вашей задачи.
Звоните get() на номер Future(), указанный scheduleWithFixedDelay(). Это будет распространять исключение обратно на подающий поток, но он будет блокироваться до тех пор, пока это не произойдет.

источник

2011-01-12 22:59:45 skaffman

Метод возвращает экземпляр ScheduledFuture, который получает методы (с тайм-аутом или без него) будет генерировать ExecutionException с вашим OutOfMemoryError в качестве причины.

источник

2011-01-12 22:52:37 jarnbjo

Итак, вы советуете всегда вызывать future.get() после планирования повторяемой задачи? Но это вызовет создание спальных нитей. Это нормально? –

Ну, вы не можете знать, выбрала ли ваша работа исключение или нет до тех пор, пока оно не будет завершено, поэтому вам придется подождать, пока он завершится успешно или не сработает (выбросьте исключение или ошибку).Если вы вызываете get с тайм-аутом 0, метод будет вызывать исключение TimeoutException, если задание все еще выполняется. Вам не нужно блокировать поток, чтобы запросить статус возвращенного Будущего. – jarnbjo

Категория ListenableFuture от guava может быть здесь полезной.

С помощью этого вы можете создать задачу обработчика исключений, которая регистрирует ошибку, а затем пытается перезапустить неудачную задачу.

Вам все еще нужен спящая нить, чтобы наблюдать за исключения, но вам нужно только один глобальный обработчик исключений потока для всего процесса (а не по одному для каждой запланированной задачи.)

источник

2011-01-12 23:06:05 finnw

Лично я отдал бы свой объект Соня вида механизма отчетности об исключениях, а не ожидать, что они будут работать с ними. Подумайте о прослушивании исключений или о подобном.

Для oom, вы можете сделать немного.

Эти исполнители съели там, чтобы выполнить ваши вещи, чтобы не справляться со всеми возможными проблемами, которые могут возникнуть у вашего кода!

источник

2011-01-13 01:48:37 time4tea

Вы можете использовать VerboseRunnable класс от jcabi-log, который перехватывает все исключения и регистрирует их:

import com.jcabi.log.VerboseRunnable; 
Runnable runnable = new VerboseRunnable(
    Runnable() { 
    public void run() { 
     // do business logic, may Exception occurs 
    } 
    }, 
    true // it means that all exceptions will be swallowed and logged 
);

Теперь, когда кто-нибудь называет runnable.run() исключения не выбрасываются. Вместо этого они проглатываются и регистрируются (до SLF4J).

источник

2013-04-06 05:37:53 yegor256

ScheduledExecutorService throwable lost

ответ

Смежные вопросы