1
Kotlin에는 검사 예외가 없으므로 인터페이스 메소드에서 예외가 발생할 것으로 예상되는 문서화 방법은 무엇입니까? 인터페이스 또는 구현 클래스에서 문서화해야합니까? (구체적 메서드가 실제로 throw하는 경우에만)?Kotlin - 인터페이스 메소드에 의해 throw 된 문서 예외
A
답변
0
클라이언트가 인터페이스에 대해 프로그램을 작성하기 때문에 해당 인터페이스의 Javadoc/KDoc에서 문서를 만들 것을 제안합니다.
Oracle 권장 : 그것이 던질 수있는 예외를 포함하는 방법의 API를 문서화하는 너무 좋은 경우
, 왜 런타임을 지정하지 당신은 실제로 예를 들어 this 스레드에서 논의되고 문서화해야하는지 여부 예외도?
런타임 예외는 프로그래밍 문제로 인해 발생하는 문제를 나타내므로 API 클라이언트 코드를 복구하거나 어떤 방식 으로든이를 처리 할 수 없다고 합리적으로 예상 할 수 없습니다. 이러한 문제에는 0으로 나누기와 같은 산술 예외가 포함됩니다. null 참조를 통해 객체에 액세스하려고하는 것과 같은 포인터 예외. 너무 크거나 작은 인덱스를 통해 배열 요소에 액세스하려고 시도하는 것과 같은 예외 인덱싱.
런타임 예외는 프로그램의 어디에서나 발생할 수 있으며 일반적으로 매우 예외적 일 수 있습니다. 모든 메소드 선언에 런타임 예외를 추가하면 프로그램의 명확성이 떨어집니다.
정보가 클라이언트에 유용 할 경우 문서화해야합니다 (예 : 클라이언트가 처리 할 수있는 경우) (예 : IOException). IllegalArgumentException과 같은 "일반"런타임 예외의 경우 "아니오"라고 말하고 문서화하지 마십시오.
'@ Throws' 주석을 사용할 수 있습니다. IMO는 이것을 인터페이스 메소드에 배치하는 것이 가장 좋습니다. –
구현에있는 경우 인터페이스를 사용하는 함수는 던져 넣을 수 있는지 또는 던질 수 있는지 알 수 없습니다. 더 나쁜 것은 두 가지 구현이 서로 다른 것을 던지는 것입니다. 참조 : [LSP] (https://en.wikipedia.org/wiki/Liskov_substitution_principle) – chris