11.11.2018, 11:04
В языках с checked exceptions бывают ситуации, когда задекларированное исключение в принципе никогда не вылетит в определенном коде, но try-catch нужно поставить, чтобы не прокидывать его выше.
Пример - метод read() класса ArrayInputStream декларирует возможный IOException, так как он пронаследован. Но он его в принципе не может выкинуть.
Пример - метод read() класса ArrayInputStream декларирует возможный IOException, так как он пронаследован. Но он его в принципе не может выкинуть.
Ловишь, логируешь, пакуешь в UncheckedIOException и передаёшь выше уже как unchecked. Если код хороший и никогда не вылетит, то подобный код не будет задействован и не будет заёбывать никого выше по стеку вызовов, а если всё-таки кто-то модифицирует что-то кривыми руками - программа всё ещё готова ловить, логировать и сигнализировать всеми способами об ошибке.
Костыль.
Вообще, программируя одновременно на жабе и скалке, я понял, что checked exceptions скорее зло, чем добро. В реальности обычно похер, что именно свалило твой поток, и мало что можно сделать, если исключение уже прилетело. И тип исключения в самом коде важен редко - не похуй ли, что залогировать?
Вообще, программируя одновременно на жабе и скалке, я понял, что checked exceptions скорее зло, чем добро. В реальности обычно похер, что именно свалило твой поток, и мало что можно сделать, если исключение уже прилетело. И тип исключения в самом коде важен редко - не похуй ли, что залогировать?
Оно то так, только некоторые ситуации вполне можно разрулить.
Синхронизация доступа к общим данным из разных потоков? Забей хуй, это гемор! Все равно при демонстрации у тебя будет только один поток, а на проде полгода будут разбираться, успеешь уволиться.
Не желаете ли немного парсинга xml регекспами, вынесенными в отдельную конфигурацию, которая в базе в виде таблицы-свалки по иерархическому шаблону property вместе с парой тысяч таких же пропертей из других мест приложения?
Если бросается исключение, и оно не обработано инструкцией try...catch, то программа скрашится. Нормой является поймать нужные типы исключений, произвести какую-то работу с ними, а затем либо кинуть выше, либо еще что-нибудь сделать, в зависимости от задачи. Обработка исключений и вывод сообщений об ошибки не связаны, это задача программиста. Поведение может быть разным - сообщение об ошибке, запись в лог, а может быть программа еще как-то это обработает. Если же оставить пустой try-catch, то ошибка перехватится, т.е. программа не упадет, но никак не будет обработана. Например, мы открываем файл, файл не найден, исключение, но оно тупо перехвачено пустым try-catch. Какое-то время спустя в другом месте программы будет предпринята попытка записи в этот файл, но он закрыт, и будет ошибка. И отыскать ее будет очень трудно, потому что причина в другом месте (ладно, пример с файлом довольно очевидный, тут легко).
Ну, не обязательно скрашится. На жабе при необработанном исключении крашится только поток, в котором оно вылетело, остальные потоки это не затрагивает. Даже если это был поток main, дочерние все продолжат работу на похуях, только если им при создании явно не выставили флаг автозавершения с парентом(это очень редко кто делает).
Не доставай дрочило, пока она сама не захочет, или хотя бы не заснет
Кроме ангела и демона есть еще дедлайн. От речей этого советника демон иногда забивается в угол и дрожит от разрывающего сознание на части ужаса.
Но ведь некоторые задачи проще написать при помощи exception driven development
boolean isNumber(String s) {
try {
int n = Integer.parseInt(s);
return true;
} catch (Throwable ex) {
}
return false;
}
boolean isNumber(String s) {
try {
int n = Integer.parseInt(s);
return true;
} catch (Throwable ex) {
}
return false;
}
Cfyz прав, return false можно перенести на одну строку вверх без изменения логики. Если поставить два, то там получится unreachable statement.
Зависит от языка программирования. Java знает и undefined return value там нет.
В жабе undefined return value - это не ворнинг, а эррор, хрен ты это скомпилишь. Про анричбл код тебе матюкнется даже на что-то типа
if (1>2) then doSome();
Это я не говорю про идею(иде), которая умеет смотреть вглубь вызовов, и предупреждать, что условие всегда true, или же то, что в этом месте значение переменной всегда будет одинаковым(и предлагать заменить всю цепочку вызовов константой, или заинлайнить код).
if (1>2) then doSome();
Это я не говорю про идею(иде), которая умеет смотреть вглубь вызовов, и предупреждать, что условие всегда true, или же то, что в этом месте значение переменной всегда будет одинаковым(и предлагать заменить всю цепочку вызовов константой, или заинлайнить код).
Кстати, кроме самого уебанства подхода, этот метод потенциально может вернуть false для вполне валидного числа. Если внутри трайкетча вылетит OutOfMemory или StackOverflow.
Кстати, да, было.
А с логгированием нужно быть осторожным, бо я сталкивался с ситуацией, когда логгинг всякой хуйни был бутылочным горлышком по производительности.
А с логгированием нужно быть осторожным, бо я сталкивался с ситуацией, когда логгинг всякой хуйни был бутылочным горлышком по производительности.
Чтобы написать коммент, необходимо залогиниться
