На этот вопрос почти "ответили до смерти", но я думаю, что есть еще несколько моментов, которые можно было бы с пользой сделать:
Использование try / catch для неисключительного потока управления - плохой стиль (в Java). (Часто идут споры о том, что означает «не исключение» ... но это другая тема.)
Отчасти причина того, что это плохой стиль, заключается в том, что try / catch на порядков дороже, чем обычный оператор потока управления 1 . Фактическая разница зависит от программы и платформы, но я ожидаю, что она будет в 1000 и более раз дороже. Помимо прочего, объект исключения creation захватывает трассировку стека, просматривая и копируя информацию о каждом кадре в стеке. Чем глубже стек, тем больше его нужно скопировать.
Другая причина плохого стиля в том, что код труднее читать.
1 - JIT в последних версиях Java 7 может оптимизировать обработку исключений, чтобы в некоторых случаях значительно сократить накладные расходы. Однако по умолчанию эти оптимизации не включены.
Есть также проблемы с тем, как вы написали пример:
Поймать Exception - очень плохая практика, потому что есть шанс, что вы случайно поймаете другие непроверенные исключения. Например, если вы сделаете это вокруг вызова raw.substring(1), вы также поймаете потенциальные ошибки StringIndexOutOfBoundsException s ... и hide .
То, что пытается сделать ваш пример, (вероятно) является результатом плохой практики работы со строками null. Как правило, вы должны попытаться свести к минимуму использование null строк и попытаться ограничить их (преднамеренное) распространение. Где возможно, используйте пустую строку вместо null, чтобы обозначать «нет значения». И когда у вас есть случай, когда вам нужно передать или вернуть строку null, четко документируйте ее в своем методе javadocs. Если ваши методы вызываются с null, когда они не должны ... это ошибка. Пусть это исключение. Не пытайтесь компенсировать ошибку, возвращая (в этом примере) null.
Followup
Мой вопрос был более общим, не только для нулевых значений.
... и большинство пунктов в моем ответе не о нулевых значениях!
Но имейте в виду, что во многих случаях вы хотите разрешить случайное нулевое значение или любое другое значение, которое может вызвать исключение, и просто игнорировать их. Это имеет место, например, при чтении значений ключа / пары откуда-то и передаче их методу, подобному tryTrim () выше.
Да, есть ситуации, когда ожидаются значения null, и вам нужно разобраться с ними.
Но я бы сказал, что то, что делает tryTrim() (обычно) - неправильный способ справиться с null. Сравните эти три бита кода:
// Version 1
String param = httpRequest.getParameter("foo");
String trimmed = tryTrim(param);
if (trimmed == null) {
// deal with case of 'foo' parameter absent
} else {
// deal with case of 'foo' parameter present
}
// Version 2
String param = httpRequest.getParameter("foo");
if (param == null) {
// deal with case of 'foo' parameter absent
} else {
String trimmed = param.trim();
// deal with case of 'foo' parameter present
}
// Version 3
String param = httpRequest.getParameter("foo");
if (param == null) {
// treat missing and empty parameters the same
param = "";
}
String trimmed = param.trim();
В конечном итоге вы должны иметь дело с null не так, как с обычной строкой, и обычно обычно - хорошая идея сделать это как можно скорее. Чем дальше разрешено распространение null от его точечного источника, тем более вероятно, что программист забудет , что значение null является возможным, и напишет ошибочный код, который предполагает не нулевое значение И забывать, что параметр HTTP-запроса может отсутствовать (т.е. param == null), это классический случай, когда это происходит.
Я не говорю, что tryTrim() изначально плох. Но тот факт, что программист чувствует необходимость в написании таких методов, как , вероятно, , свидетельствует о неоптимальной обработке нуля.