Рефакторинг обработки исключений

Question

Хорошо, я согрешил, я написал слишком много кода, подобного этому

try {
   // my code
} catch (Exception ex) {
   // doesn't matter
}

Теперь я собираюсь почистить / реорганизовать это.

Я использую NB 6.7, и завершение кода отлично работает при первом написании, добавлении всех типов исключений и т. Д. После того, как я выполнил приведенный выше код, NB больше не помогает.

Знаете ли вы, как сказать NB, снова посмотрите на все типы исключений и внесите предложение по их обработке и снова выполните завершение кода?

Answer 1

PMD идентифицирует все эти места, где у вас есть пустые блоки catch (на самом деле PMD делает гораздо больше). Он имеет интеграцию с NetBeans, поэтому попробуйте.

После определения всех мест с пустыми catch блоками вам придется рассмотреть каждое из них по отдельности:

• иногда просто логировать сообщение
• иногда реструктурирует соседний код. То есть если вы ловите NullPointerException, добавьте вместо него null.
• иногда вам придется подумать об отбрасывании (и объявлении проверенных) исключений.

Answer 2

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

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

Совет. Выполните автоматическое форматирование кода, выполните поиск по номеру try и выделите квадратные скобки, чтобы найти соответствующие блоки catch. Затем удалите весь код обработки.

После этого Netbeans снова предложит различные действия для обработки возможных исключений.

PS: будьте осторожны, обработка NetBeans по умолчанию (т. Е. Просто ведение журнала) также не всегда является лучшим выбором.

Answer 3

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

Нет общепринятого способа справиться с ними. В противном случае, вы держите пари, что Java-язык будет иметь такое поведение.

• Исключения не являются ограничением низкого уровня, с которым нужно иметь дело, пока компилятор не станет достаточно умным.
• Исключения - это языковая конструкция высокого уровня, используемая для выражения семантики "произошло что-то исключительное, чье обращение вы не хотите смешивать с обычным кодом; вы предпочитаете, чтобы оно обрабатывалось в определенных кодах".

---

Исключения существуют в двух формах:

• Проверенные исключения должны быть явными в каждом методе, который может их генерировать.
• Непроверенные исключения (подклассы RuntimeException или Error) обычно являются неявными.

На каждом уровне кода (метод или блок) код должен выбирать, что делать в случае любого исключения (кроме непроверенных исключений, которые могут вообще пропустить обработку). Это выбор ответственности, который варьируется, и не существует решения, действительного для всех случаев:

• PROCESS : перехватить и полностью обработать (вызывающие коды обычно не знают, что что-то произошло). Текущий метод должен нести ответственность. Регистрация трассировки стека для разработчика может быть полезной.
• STEP : поймайте его, выполните шаг обработки, связанный с локальным кодом, и перебросьте его (или перебросьте другое исключение с исходным в качестве причины).
• IGNORE : просто возьмите на себя ответственность вызывающего кода.

Язык Java позволяет вам иметь определенные синтаксисы, упрощающие обработку исключений, например, перехват определенных исключений и более общие ...

---

Как правило, вы учитываете исключения в своей архитектуре и принимаете некоторые проектные решения. Некоторые примеры (смешанные уникальными способами):

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

Answer 4

Я просто могу представить подход к затмению и надеюсь, что он немного похож на netbeans:

1. удалить операторы try / catch -> eclipse покажет ошибки компилятора
2. используйте быстрый совет eclipse для рефакторинга правильных операторов try / catch (или throw)

Вы можете сохранить существующий код обработки исключений, чтобы вставить его после рефакторинга.

Редактировать

У Тома был очень хороший комментарий относительно RuntimeException. Так что процедура должна выглядеть так:

1. скопировать существующее предложение catch и вставить в блокнот / текстовый редактор
2. удалить операторы try / catch -> eclipse покажет ошибки компилятора
3. используйте быстрый совет eclipse для рефакторинга правильных операторов try / catch (или throw)
4. вставить сохраненное предложение catch в конце последовательности операторов catch

Это сохранит обработку исключений RuntimeExceptions (и подтипов!).

Так от

try {
   Integer.parseInt("Force a RuntimeException");
   myInputStream.close();
} catch (Exception oops) {
   // catch both IOException and NumberFormatException
}

вы идете на

try {
   Integer.parseInt("Force a RuntimeException");
   myInputStream.close();
} catch (IOException oops) {
   // catch IOException
} catch (Exception oops) {
   // catch NumberFormatException
}

(хотя вы можете вручную заменить Exception на NumberFormatException в этом случае, но это всего лишь пример)