Поймайте и протоколирования для неуместных операций

Я метод, чтобы сохранить информацию о каждой операции синхронизации:Поймайте и протоколирования для неуместных операций

public void queueTimerInfo(long start, long end, String msg) { 
     try { 
      timer.queue(start, end, msg); 
     } catch (InterruptedException e) { 
      Logger.info(e.getMessage()); 
     } 
    }

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

Но мне всегда говорили, что регистрация без управления исключением - это плохая практика. Итак, как мне переписать вышеуказанный код?

источник

2015-09-21 user1883212

Если этой операции не разрешено нарушать функциональные возможности вашего кода, что бы вы сделали? бросить исключение? – Stultuske

Добавить 'Thread.currentThread(). Interrupt();' в конце блока catch – Natalia

Вы просто не должны переписывать код –

Если вы знаете последствия, то есть может быть прерван вызов timer.queue(), а не очередь на данные, и вы можете жить с ним, тогда это нормально игнорировать Исключение. Как и в большинстве правил, вам нужно знать, когда их нарушать.

Однако я бы задокументировал ваше решение с комментарием в блоке catch, так что тот, кто поддерживает код позже, знает, что не обработка Исключения не является надзором, а преднамеренным решением.

источник

2015-09-21 11:17:05

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

источник

2015-09-21 11:18:12 bsingh

Регистрация времени по очереди не должна влиять на окружающий код, поэтому ретронж является плохим выбором! –

Но я всегда говорил, что вход без управления исключением плохой практика

Что означает «управление» означает? Повторить их? Слегка следуя шагам 1, 2, 3, потому что «zOMG исключено исключение !! 111»?

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

Задайте себе вопрос: не исключено ли это исключение? Разрывает ли он контракт? Меняет ли поток ваше приложение? Вы абсолютно не хотите, чтобы это произошло, и если да, то ситуация действительно исключительная, и вы должны действительно справиться с этим как-нибудь?

Если это не имеет значения и т. Д., То просто заносить в журнал это вполне приемлемо. Это действительно сводится к вашему контексту и значению вашего исключения.

LE: Конечно, как предлагает Томас, вы можете документировать свое решение.

источник

2015-09-21 11:37:01 async

InterruptedException особенный, потому что это не сигнализирует об ошибке.

Когда метод объявляет InterruptedException, он сообщает вам, что это метод блокировки, который можно отменить, прервав его поток. Брайан Гетц explains:

Когда метод бросает InterruptedException, он говорит вам, что если поток выполнения метода прерывается, он будет сделать попытка остановить то, что он делает и вернуться рано и указать его раннее возвращение, бросая InterruptedException.Хорошо организованная блокировка Методы библиотеки должны реагировать на прерывание и бросать InterruptedException, чтобы они могли использоваться в рамках отмененных действий без ущерба для реагирования.

Вы должны либо

не поймать исключение и добавить throws InterruptedException
поймать его, не чистить и повторно выдать его
, когда вы не можете бросить его (например, в a Runnable) позвонить по телефону Thread.getCurrentThread().interrupt();

Если вы просто проглотите исключение, r.

источник

2015-09-21 11:53:48 wero

Поймайте и протоколирования для неуместных операций

ответ

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