81 подписчик
🖥 Хороший стиль обработки ошибок
Правильная и хорошая обработка ошибок — довольно важная часть в разработке. Но как это делать правильно?
⏩Когда делать RuntimeException, а когда просто Exception
⏩Единственен ли способ генерации ошибки оператором throw?
⏩В каких лучше случаях создать, допустим, MyException extends Exception, а затем MyOtherException extends MyException? Иными словами, как увидеть необходимость в иерархии ошибок?
⏩Когда делать примерно так:
public void f() throws MyException {
//некоторый код ...
if (....){
throw MyException(...);
}
}
⏩Какие еще есть способы генерации ошибок?
⏩Когда правильнее переносить ошибку на уровень функции (... f() throws ...)?
▶️Что ж, попробуем на это ответить.
Во-первых, используйте исключения. Создайте свою иерархию исключений и продумайте, какие из них сделать *runtime*, а какие нет. Никогда не используйте конструкции типа new Exception(...) или new RuntimeException. Вместо этого старайтесь создавать и кидать только адекватные ситуации исключения. Создание экземпляра Exception или RuntimeException — халтура и отписка вместо обработки ошибок.
Не забывайте проверять все параметры в конструкторах и, по возможности, в методах и своевременно кидать IllegalArgumentException. Пользуйтесь стандартными исключениями в соответствующих случаях. Используйте их по назначению и никогда не кидайте что попало.
Пользуйтесь try/catch/finally. Не забывайте уничтожать ресурсы.
Пользуйтесь логгерами, а не делайте e.printStackTrace. Никогда не делайте catch пустым, если только вы не уверены, что должны именно проигнорировать исключение.
При логгировании пользуйтесь по возможности полный метод log с уровнем логгирования, сообщением и исключением. Старайтесь в сообщении к логу описать, что именно упало и добавить какие-то сведения об условиях в блоке try. Это поможет выявить проблемы в боевых условиях. Старайтесь назначать адекватные уровни логгирования.
1 минута
16 апреля 2024