Используйте исключения, а не коды возврата
Иногда мы склонны обрабатывать ошибки в блоках if else. Это беспорядочно, потому что смешивается с логикой. Использование исключений, их генерация или обработка могут быть лучше.
Сначала напишите оператор Try-Catch-Finally
Исключения хороши тем, что они определяют область действия ошибки. А блок try-catch-finally должен оставлять программу в согласованном состоянии. Автор предполагает, что когда мы создали нашу структуру try-catch-finally, наша область действия определена, и мы можем продолжить остальную логику.
Проблемы с проверенными исключениями
Автор объясняет, что проверенные исключения на самом деле не стоят своей цены. Его цена определяется принципом открытости/закрытости. Если вы выдаете проверенное исключение из метода в своем коде, а перехват находится на три уровня выше, вы должны объявить это исключение в сигнатуре каждого метода между вами и перехватчиком. Это нарушает инкапсуляцию, поскольку сведения о коде, содержащем это исключение, должны быть известны всем методам в пути.
Предоставить контекст с исключениями
Сообщить о том, какая операция завершилась сбоем и какой это тип ошибки.
Определите классы исключений с точки зрения потребностей вызывающего абонента
Определите свои собственные исключения. Иногда фрагмент кода может генерировать множество типов исключений. Но с точки зрения приложения это может быть сбой одной операции. Таким образом, мы можем написать новый класс исключений, чтобы генерировать пользовательское исключение всякий раз, когда выдаются определенные типы исключений. Это делает код более читабельным и понятным.
Определите нормальный поток
попробуйте {
MealExpenses расходы = расходReportDAO.getMeals(employee.getID());
m_total += расходы.getTotal() ;
} catch(MealExpensesNotFound e) {
m_total += getMealPerDiem();
}
В приведенных выше случаях мы видим, что обработка ошибок и логика запутались, это плохо. Таким образом, мы можем заставить метод getMeals возвращать пустой объект, когда из db нет блюд.
Не возвращайте значение null
возврат значения null ведет к ошибкам. Вместо этого верните пустое представление этого необходимого объекта.
Не передавать null
передача null хуже, чем возврат null. Склонен к исключениям nullpointer. В этом случае также можно передать пустые объекты, но это зависит от дизайна.
