예를 들어 프레임 워크 / JDK의 많은 메소드에서
java.lang.SecurityException
그러나 이것은 메서드 서명에 표시되지 않습니다 (일반적으로 확인 된 예외에 대해 예약 된 관행이기 때문에). 메소드 sigs에서 RuntimeExceptions를 선언하면 많은 이점이 있다고 주장하고 싶습니다 (예를 들어 정적 유형 검사와 유사). 내가 술에 취했습니까?
예를 들어 프레임 워크 / 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.
인내심이 있다면 이런 식으로 메서드에서 발생할 수있는 예외를 철저히 문서화하는 것이 좋습니다. 어떤면에서는 확인되지 않은 예외에 대해이 작업을 수행하는 것이 훨씬 더 중요합니다. 확인 된 예외는 다소 자체 문서화되어 있기 때문입니다 (컴파일러는 호출 코드가이를 확인하도록 강제합니다).
throws메소드 서명 에 대한 질문 동안 Javadoc 문에 대해 이야기하고 있습니다. 이것들은 같은 것이 아닙니다. 예, API에서 발생하는 모든 예외를 문서화 해야 하지만 문제가 아닙니다.