1.
2.
3.
4.
5.
6.
7.
static Optional<LocalDate> parseOrEmpty(String d1) {
try {
return Optional.of(LocalDate.parse(d1, dateTimeFormatter));
} catch (DateTimeParseException ex) {
return Optional.empty();
}
}
Согласен. Так и получается, что исключения гасить в самом зародыше. Чтобы наружу ни в потоках, ни в стримах не выползали.
Да. Большинство языков которые создавались после Java (GoLang) отказались от декларации checked exceptions
и вообще постарались не вовлекать программиста в формальный протокол обработки до тех пор пока
ОН САМ не решит это сделать явно. Да и вообще. Если есть возможность например парсить дату
просто возвращая boolean признак - лучше сделать так. Это будет дешевле с точки зрения накладных
расходов на процессинг. Представте что вы парсите CSV-файл из миллиарда строк и в нем в каждой
строке идет генерация DateTimeParseException и внутренняя механика каждый раз (!) формирует
полный стектрейс (Java объект представляющий стектрейс) независимо от того нужен он нам или нет.
По сабжу - не нужен но бох его знает какая механика под капотом уже работает. Софистический
пример с парсингом дат - для меня был самый настоящий. И я фиксил перформанс дефект
как раз для такого случая когда формат даты был задан неверно но деградация производительности
(для JDK 1.6) в то время была так ужасна что выгоднее было сделать строковые проверки
и выйти из процедуры раньше чем отработает метод ::parse().
Вобщем Exception - должен быть редким. Исключительным.
