메서드에서이 NumberFormatException을 catch해야합니까?

Question

내가

void A(long input) { 

    ...... 

} 

같은 방법이 있다고 가정 기본적으로 입력이 길거나 다른 형식을 오래 변환 할 수있을 때 잘 작동합니다.

그러나 잘못된 데이터 입력이 있으면 NumberFormatException이 발생합니다. 따라서 강력한 방법은

void A(long input){ 

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

    } 

} 

이어야합니다. 그러나 일부 개발자는 프로젝트가 BS 응용 프로그램이라고 주장합니다. 따라서 입력은 웹 UI에서 전달됩니다. 따라서 입력이 유효한지 확인할 수 있습니다. 그리고이 예외를 처리 할 필요가 없습니다.

그러나 나는 그것이 반드시 필요하다고 생각합니다. 어떻게 생각해? 감사.

Answer 1

함수 내에서 예외를 catch할지 여부는 실제로 선택입니다. 함수 스펙이 도움이됩니다.

그러나 함수에서 아무 것도 반환하지 않기 때문에 발신자가 잘못된 것이 발생했음을 알리는 방법은 무엇입니까? 상관 없으면 잡는 것이 좋습니다. 문제가 발생하면 예외 전파는 오류의 존재를 알리는 좋은 방법입니다 (함수 서명이 변경되지 않는 한).

Answer 2

나는 그것을 사용하지 않고 필요로하지 않는 try-catch 블록을 사용하는 것이 좋습니다. 입력이 웹 UI로 전달된다는 사실은 향후 유효성 검사 로직을 수정할 수 있음을 의미합니다.

그러나 사용자가 오류를 알리는 지 확인해야합니다.

Answer 3

메서드가 long을 허용하면 메서드 자체에는 변환이 없습니다. 메서드가 호출되기 전에 인수가 스택으로 푸시 될 때 변환되므로 변환을 catch 할 수 없습니다 메소드 자체의 오류.

인수가있는 String을 전달하려면 고유 한 변환을 수행해야하며 예외를 catch하거나 throw해야합니다. 어느 쪽이든 똑같이 유효 할 수 있으며, 선택은 유효하지 않은 값을 처리하려는 방법에 달려 있습니다. "이것이 실제로 숫자가 아닙니다"라는 예외를 던지려는 경우 예외를 던져 버릴 수도 있습니다.

Answer 4

경우에 따라 코드에서 예외적 인 조건이 발생할 수 없다는 것을 99.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 5

대답은 시스템 설계에 따라 달라집니다 : 나머지 0.5 %는 응용 프로그램이나 데이터베이스의 일관성을 해칠 수 있다면 나쁜 일이 발생하기 전에, 예외를 잡아 런타임 예외를 throw하는 것이 좋습니다 수 있습니다. 이 데이터 형식 유효성 검사를 수행 할 수있는 웹 UI의 책임 인 경우 다음 단계는 그 유효성 검사가 완료되었습니다 가정하고 NumberFormatException 전파 할 수 있도록하는

• 은, 그것은 합리적이다. 그러나 어떤 시점에서 서버 측 코드는 (예기치 않은) 예외를 잡아서 로그에 기록하고 적절한 HTTP 응답 코드를 생성해야합니다.

• 데이터 형식 유효성 검사를 수행하는 것이 웹 UI의 책임이 아니라면 다음 수준에서 적절한 (사용자에게 친숙한) 오류 메시지를 생성하고 사용자가 쉽게 수정할 수 있도록해야합니다. (예를 들어, HTML로 구현 된 웹 UI는 어느 정도 데이터의 유효성을 검사 할 수 없습니다.)

검증의 다양한 종류에 대한 책임이 어디에 속해 시스템 설계가 명확하게 지정하지 않는 경우, 디자인에 결함이 있습니다.

또한 유효성을 검사 한 후에 숫자를 문자열로 전달하는 것이 좋은지 여부를 고려해야합니다. 이것은 필요할 수 있습니다. 예 : 레이어가 별도의 웹 응용 프로그램 컨테이너에있는 경우 그러나 유효성 검증과 비즈니스 로직이 동일한 서블릿에있는 경우, 전자는 int 또는 long을 전달해야하며 후자에 숫자의 표현은 String이 아니어야합니다.

마지막으로, 개념적으로 내부 웹 api가 실제로 공개되면 해킹으로부터 사용자를 보호 할 수있는 충분한 검증을 수행해야합니다. 예를 들어 사용자 지향 웹 UI가 HTML + Javascript 인 경우 통신 할 노출 된 HTTP 기반 API가 있어야합니다. 해커가 GUI를 우회하여 HTTP API 디렉토리로 이동하는 것은 간단합니다. 따라서 HTTP API는 최소한 악용 시도에 필요한 정도로 요청을 확인해야합니다.