Должен ли я поймать это NumberFormatException в методе?

Question

Предположение, что у меня есть метод, подобный

void A(long input) {

  ......

}

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

Но, когда вводятся некоторые неправильные данныеКидаем туда NumberFormatException.Таким образом, надежный метод должен быть

void A(long input){

   try{
       ...
   }catch(NumberFormatException e){

   }

} 

Однако некоторые разработчики утверждают, что проект является приложением BS.Таким образом, ввод передается из веб-интерфейса.Таким образом, он может подтвердить, что ввод действителен.И нет необходимости обрабатывать это исключение.

Но я думаю, что это необходимо.Как вы думаете?Благодарю.

Answer 1

Если метод принимает long, то внутри самого метода нет преобразования - аргумент будет преобразован при его переносе в стек до вызова метода, и вы не сможете перехватитьошибка преобразования в самом методе.

Если вы хотите передать String с аргументом, то вы будете выполнять свое собственное преобразование - и вам нужно либо перехватить исключение, либо позволить емувыброшены.Любой способ может быть одинаково действительным, и выбор зависит от того, как вы хотите обрабатывать недопустимые значения.Если вы просто собираетесь выдать исключение, которое говорит: «на самом деле это не число» или что-то в этом роде, то вы можете просто разрешить этому исключению.

Answer 2

Ответ на этот вопрос зависит от вашей системы.

• Если веб-интерфейс отвечает за проверку типа данных, то на следующем уровне разумно предположить, что проверка была выполнена, и разрешить распространение NumberFormatException. Однако в какой-то момент код на стороне сервера должен перехватить (неожиданное) исключение, зарегистрировать его и создать соответствующий код ответа HTTP.

• Если веб-интерфейс не отвечает за проверку типа данных, то на следующем уровне необходимо создать подходящее (удобное для пользователя) сообщение об ошибке и упростить его для пользователя. (Например, веб-интерфейс, реализованный только в HTML, не сможет проверять данные в какой-либо степени.)

Если в проекте вашей системы неясно указано, к чему относится ответственность за различные виды валидации, тогда дизайн ошибочен.

Вам также следует подумать о том, стоит ли передавать числа в виде строк после их проверки. Это может быть необходимо; например если слои находятся в отдельных контейнерах webapp. Но если проверка и бизнес-логика находятся в одном и том же сервлете, то первый должен передавать int или long, а не String представление числа второму.

Наконец, если какой-либо из условно внутренних веб-интерфейсов фактически выставлен, вы должны по крайней мере сделать достаточно проверки, чтобы защитить их от взлома. Например, если пользовательский веб-интерфейс представляет собой HTML + Javascript, то также должен существовать открытый API-интерфейс на основе HTTP, с которым он взаимодействует. Для хакера несложно обойти ваш графический интерфейс и поговорить с HTTP API. Таким образом, HTTP API должен проверять запросы, по крайней мере, в объеме, необходимом для предотвращения попыток взлома.

Answer 3

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

private void String(String validatedStringWithALongValue) {
  try {
     long l = Long.parseLong(validatedStringWithALongValue);
     // ... do what has to be done
  } catch (NumberFormatException oops) {
     Exception e = new RuntimeException(oops);
     log.error("Bad news - validation failed or has been bypassed", e);
     throw e;
  }
}

Answer 4

Я думаю, что лучше иметь блок try-catch, который никогда не используется, чем не иметь его и нуждаться в нем.Тот факт, что входные данные передаются в веб-интерфейс, означает, что любая логика проверки может быть изменена в будущем.

Однако необходимо убедиться, что пользователь уведомлен об ошибке.

Answer 5

Стоит ли перехватывать исключения внутри функции - это действительно выбор. Спецификация функции помогает.

В вашем случае, однако, поскольку функция ничего не возвращает, как вызывающий должен знать, что произошло что-то не так? Если это не имеет значения, то ловля может подойти. Если это имеет значение, то распространение исключения является хорошим способом уведомления о существовании ошибки (если только сигнатура функции не изменена).