Еще на тему
TOR и VPN
Популярные Комиксы
 | Комиксы Cyanide and happinessРейтинг: 79,579.0 |
 | cynic mansionРейтинг: 69,221.6 |
 | JaGoРейтинг: 68,098.0 |
 | ОглафРейтинг: 57,050.2 |
 | countryballsРейтинг: 48,190.0 |
 | BuniРейтинг: 45,073.3 |
 | pet_fooleryРейтинг: 43,938.9 |
 | SMBCРейтинг: 42,186.1 |
 | slack wyrmРейтинг: 39,451.0 |
 | duran artРейтинг: 37,844.6 |
Сейчас на сайте
Всего пользователей на сайте: 696
Пример - метод read() класса ArrayInputStream декларирует возможный IOException, так как он пронаследован. Но он его в принципе не может выкинуть.
Вообще, программируя одновременно на жабе и скалке, я понял, что checked exceptions скорее зло, чем добро. В реальности обычно похер, что именно свалило твой поток, и мало что можно сделать, если исключение уже прилетело. И тип исключения в самом коде важен редко - не похуй ли, что залогировать?
Код не работает, но и помалкивает.
Иди гадай, что с ним не так, если этот код писал не ты.
а поддерживать придется
boolean isNumber(String s) {
try {
int n = Integer.parseInt(s);
return true;
} catch (Throwable ex) {
}
return false;
}
Вот что он точно знает, так это то, что если убрать return false из самого конца функции, то формально это будет функция с undefined return value.
if (1>2) then doSome();
Это я не говорю про идею(иде), которая умеет смотреть вглубь вызовов, и предупреждать, что условие всегда true, или же то, что в этом месте значение переменной всегда будет одинаковым(и предлагать заменить всю цепочку вызовов константой, или заинлайнить код).
А с логгированием нужно быть осторожным, бо я сталкивался с ситуацией, когда логгинг всякой хуйни был бутылочным горлышком по производительности.