예를 들어 프레임 워크 / JDK의 많은 메소드에서
java.lang.SecurityException
그러나 이것은 메서드 서명에 표시되지 않습니다 (일반적으로 확인 된 예외에 대해 예약 된 관행이기 때문에). 메소드 sigs에서 RuntimeExceptions를 선언하면 많은 이점이 있다고 주장하고 싶습니다 (예를 들어 정적 유형 검사와 유사). 내가 술에 취했습니까?
답변
서명에서 확인되지 않은 예외는 해당 API의 사용자에게 오해의 소지가 있으므로 선언하지 않습니다. 예외를 명시 적으로 처리해야하는지 여부는 더 이상 명확하지 않습니다.
javadoc에서 선언하는 것은 누군가가 필요하다고 생각하는 경우 처리 할 수 있지만 원하는 경우 무시할 수 있다는 것을 알기 때문에 더 나은 접근 방식입니다. 이렇게하면 선택됨과 선택되지 않음 사이의 구분이 명확 해집니다.
답변
에서 오라클 자바 튜토리얼 :
“발생할 수있는 예외를 포함하여 메서드의 API를 문서화하는 것이 너무 좋다면 런타임 예외도 지정하지 않는 이유는 무엇입니까?” 런타임 예외는 프로그래밍 문제의 결과 인 문제를 나타내므로 API 클라이언트 코드는 이러한 문제로부터 복구하거나 어떤 방식 으로든 처리 할 수 없습니다. 이러한 문제에는 0으로 나누기와 같은 산술 예외가 포함됩니다. null 참조를 통해 객체에 액세스하려는 것과 같은 포인터 예외 및 너무 크거나 너무 작은 인덱스를 통해 배열 요소에 액세스하려는 시도와 같은 인덱싱 예외.
런타임 예외는 프로그램의 어느 곳에서나 발생할 수 있으며 일반적인 예외는 매우 많을 수 있습니다. 모든 메서드 선언에 런타임 예외를 추가해야하는 것은 프로그램의 명확성을 떨어 뜨립니다.
답변
Collection # add에 대한 javadoc을 살펴보십시오.
확인되지 않은 예외가 많이 언급되었습니다.
Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.
인내심이 있다면 이런 식으로 메서드에서 발생할 수있는 예외를 철저히 문서화하는 것이 좋습니다. 어떤면에서는 확인되지 않은 예외에 대해이 작업을 수행하는 것이 훨씬 더 중요합니다. 확인 된 예외는 다소 자체 문서화되어 있기 때문입니다 (컴파일러는 호출 코드가이를 확인하도록 강제합니다).
답변
내 관점에서 적어도 메서드의 javadoc에서 런타임 예외를 선언하는 것이 좋습니다. 서명에서 선언하면 문제가 발생할 때 발생할 수있는 일이 더욱 분명해집니다. 이것이이 정보 제공을 제안하는 주된 이유입니다.
참고 : 시간이 지남에 따라 (현재 2017 년) 이제 javadoc에서만 문서화하고 가능한 한 많이 확인 된 예외를 피하는 데 더 많이 기울고 있습니다.
답변
내 관점에서 확인되지 않은 예외는 속성에 반하는 메서드 서명에서 선언되어서는 안됩니다.
그러나 메소드가 Javadoc의 @throws에서 발생할 수있는 상황을 지적하는 일부 확인되지 않은 예외를 던질 가능성이있는 경우 다른 사람이 잘못된 방법을 이해하는 데 메소드를 호출하는 데 도움이 될 수 있습니다. 이는 호출자가 처리 할 수있는 예외 (예 : 잘못된 입력으로 인한 NPE 등)에만 유용합니다.
답변
다른 사람이 사용할 api를 작성하는 경우 api에서 의도를 명시 적으로 문서화 할 충분한 이유가 있으며 메소드 서명에서 RuntimeExceptions를 선언하는 데 단점이 없습니다.
