Является ли перехват NumberFormatException плохой практикой?

Обработка исключений является неотъемлемой частью (и одной из целей разработки) языка программирования Java ... вы не должны отказываться от них только потому, что считаете их «уродливыми».

Тем не менее, если вам нужен простой и понятный способ обработки NumberFormatExceptions, вы можете вместо этого рассмотреть возможность использования класса NumberUtils.

Метод toInt(String str, int defaultValue) преобразует String в int, возвращая значение по умолчанию, если преобразование не удалось. Если строка null, возвращается значение по умолчанию.

 NumberUtils.toInt(null, 1) = 1
 NumberUtils.toInt("", 1)   = 1
 NumberUtils.toInt("1", 0)  = 1

Этот метод инкапсулирует перехват и обработку исключений, как показано в исходном коде ниже. В результате клиенту нужно сделать только один вызов метода.

public static int toInt(String str, int defaultValue) {         
    if(str == null) {
        return defaultValue;
    }
    try {
        return Integer.parseInt(str);
    } catch (NumberFormatException nfe) {
        return defaultValue;
    }
}

Это ваш второй вопрос, который я сегодня видел по этому поводу.

Нет, это исключение вполне уместно.

И это определенно лучшая форма для перехвата более явного исключения (например, «NumberFormatException»), чем универсальное «Exception».

ПО МОЕМУ МНЕНИЮ...

PS: Где вы ставите исключение: на этом уровне или выше - это другой вопрос.

Эмпирическое правило - «самый низкий уровень, на котором вы знаете, что произошло, и как лучше всего восстановиться».

Или, иначе говоря (цитата из ссылки ниже):

«Метод должен перехватывать исключение только в том случае, если он может обработать его разумным способом».

Вот обсуждение:

• Почему я не должен заключать каждый блок в try-catch?

Нет, это не «плохая практика». Это просто зависит от ситуации.

Например, в Android, если пользователь вводит строку «123a» в текстовое поле, которое должно принимать только целые числа, и впоследствии анализируется, будет выдано исключение, вызывающее сбой приложения. В этом случае имеет смысл перехватить исключение и предложить пользователю повторно ввести текст.

В вашем случае я бы предпочел использовать NumberFormatException что-то вроде метода isHexDigit, если только вы не сделаете каких-либо предположений относительно формата ваших данных - из вашего описания кажется, что нет таких предположений о том, когда вы столкнетесь с шестнадцатеричным числа против не шестнадцатеричных чисел.

Это связано с тем, что исключения должны использоваться для обработки исключительных условий, и если ожидание от ваших данных: шестнадцатеричные или не шестнадцатеричные цифры, разделенные пробелами, тогда существует ничего особенного в том, чтобы встретить жетон, отличный от шестнадцатеричной цифры.

Кроме того, использование Exception делает менее читабельным код: без комментариев к данным он скрывает тот факт, что перемежающиеся не шестнадцатеричные цифры являются приемлемым и ожидаемым вводом.

Сказав это предпочтение, я мог бы использовать обработку исключений для обработки этого случая, и я определенно вижу много кода, который это делает. В этой комбинации decode / parseInt / NumberFormatException для вас заключено множество хороших функций. Я бы не стал использовать это без явного комментария, четко объясняющего, что я делаю.

Это зависит от контекста, во многих случаях это плохо, но если это будет место, которое, скорее всего, будет иметь неправильный ввод, и у вас есть значение по умолчанию, которое нужно установить, тогда вы захотите его поймать.

Это Not about how good you code looks, но _2 _.......... Ya offcourse it should be readable, Как известно ...

Любой дурак может написать код, понятный компьютеру, но только великие программисты могут писать коды, понятные людям.

Это прекрасно в некоторых случаях, когда вам нужно иметь такие исключения.

When you want to catch multiple exceptions which belong to the same inheritance tree, then create a try block, and multiple catch blocks from more specific to more abstract.

eg:

`Animal <--- Carnivores <--- Dog`

Теперь предположим, что есть DogException, CarnivoresException, AnimalException.

Тогда должно быть так,

try{

           // your code 

     }
      catch(DogException d){}
      catch(CarnivoresException c){}
      catch( AnimalException a){}

Вышеупомянутые перехватчики были каскадированы от более конкретных к более абстрактным, так что исключение перехватывается по самой причине.

Если нет наследования, то ловить можно в любом порядке ...

Это лучшее, что ты можешь сделать. Метод либо вернет какой-то индикатор успеха / ошибки, либо вызовет исключение, это просто вопрос, что наиболее удобно. Здесь Sun приняла решение за нас, поэтому нет необходимости в дебатах.

Что меня больше всего беспокоит, так это то, что исключение будет включать полную трассировку стека! В вашем конкретном случае, если вы читаете миллионы этих строк, вы заметите (совершенно ненужную) низкую производительность. Если это важно для вас, вы можете подумать о написании собственного метода (вы можете использовать код Sun в качестве руководства). Затем вы можете решить для себя, хотите ли вы использовать исключение или нет. Если вы это сделаете, держите под рукой статическую копию исключения и всегда бросайте ее, чтобы сэкономить время. И переопределите fillInStackTrace, чтобы он ничего не делал, и у вас не было бессмысленной трассировки стека в вашем исключении.