“프로그래밍 오류”예외 – 접근 방식이 적절합니까?

현재 예외 사용을 개선하려고 노력 중이며 프로그래밍 오류를 나타내는 예외 (예 : 누군가 인수로 null을 전달했거나 처리 된 후 객체에서 메서드를 호출 한 예외)와 응용 프로그램에서 오류를 나타내는 예외 간의 중요한 차이점을 발견했습니다. 호출자의 결함이 아닌 작업 (예 : I / O 예외)

이 두 종류의 예외를 어떻게 다르게 취급해야합니까? 오류 예외를 명시 적으로 문서화해야하거나 관련 전제 조건을 문서화하기에 충분하다고 생각하십니까? 그리고 사전 조건 또는 오류 예외가 명백해야하는 경우 (예 ObjectDisposedException: 처리 된 객체에서 메서드를 호출 할 때) 문서를 생략 할 수 있습니까?

나는 당신이 올바른 길을 가고 있다고 생각합니다. 잠재적으로 던져 질 수있는 예외를 모두 던지거나 잡거나 문서화하는 것은 의미가 없습니다. 제품 엄격 성이 높은 수준의 예외 고용 및 문서화를 요구하는 경우가 있습니다 (예 : 시스템의 특정 안전 중요 측면).

계약 개념을 사용하여 특히 다운 스트림 발신자 (예 : 공공 또는 보호 회원과 유사한 것)에 대한 전제 조건 (및 사후 조건)을 식별하는보다 방어적인 전략은 종종보다 효과적이고 유연합니다. 이는 구현뿐만 아니라 문서에도 적용됩니다. 개발자가 예상되는 것을 알면 규칙을 따르는 경향이 있으며 작성한 코드를 혼동하거나 오용 할 가능성이 줄어 듭니다.

문서화해야 할 일반적인 사항 중 일부는 널 매개 변수의 경우입니다. 일반적으로 예상되지 않는 결과로 이끄는 사용 결과가 종종 있지만 여러 가지 이유로 허용되며 때로는 유연성을 위해 사용되기도합니다. Null 또는 기타 특수하고 비이성적 인 값 (음수 시간 또는 음수와 같은)을 허용하는 매개 변수가있는 구성원의 소비자로서 나는 그것들이 식별되고 설명되는 것을 볼 것으로 기대합니다.

null이 아닌 매개 변수의 경우 공용 또는 보호 멤버의 소비자로서 null이 허용되지 않는다는 것을 알고 싶습니다. 주어진 맥락에서 유효한 값의 범위가 무엇인지 알고 싶습니다. 정상 범위를 벗어난 값을 사용하지만 다른 호출 컨텍스트에서 유효한 값을 사용하는 결과를 알고 싶습니다 (예 : 유형의 값은 일반적으로 모든 작업에 유효하지만 여기서는 아닙니다)-부울 매개 변수 유효한 값으로 거짓을 기대하지 마십시오.

플랫폼 또는 잘 알려진 인터페이스에 관해서는 문서화에 극도로 갈 필요가 없다고 생각합니다. 그러나 개발자는 플랫폼 지침에 따라 구현을 다양화할 수있는 기회가 있으므로 지침을 따르는 방법에 유의하십시오.

IDisposable과 관련하여, 종종이 인터페이스의 구현은 명시 적 폐기 프로세스보다 선호되는 대체 방법을 제공합니다. 이 경우 선호하는 방법을 강조 표시하고 명시적인 처리가 바람직하지 않다는 점에 유의하십시오.

여기 내 자신의 생각이 있습니다. 나는 이것이 최선의 방법이라고 확신하지 못하기 때문에 처음 에이 질문을 만들었습니다.

내가 이해하는 한, 즉각적인 호출자가 실제로 프로그래밍 오류 예외를 처리하는 것은 의미가 없으며 대신 전제 조건이 충족되는지 확인해야합니다. 작업 경계에서 "외부"예외 처리기 만 처리해야하므로 작업이 실패 할 경우 시스템을 계속 실행할 수 있습니다.

실수로 오류 예외를 포착하지 않고 클라이언트 코드가 "실패한"예외를 명확하게 포착 할 수 있도록하기 위해, 이제 모든 실패 예외에 대해 고유 한 예외 클래스를 작성하여이를 예외 메소드에 문서화합니다. Java에서 예외를 확인하도록 만들 것입니다.

최근까지 메소드가 던질 수있는 모든 예외를 문서화하려고 시도했지만 때로는 오류가 발생하지 않음을 나타낼 때까지 호출 체인의 모든 메소드에 문서화 해야하는 불필요한 목록을 작성하는 경우가 있습니다. 대신, 나는 이제 전제 조건을 요약 / 매개 변수 설명에 문서화하고 이들이 충족되지 않으면 어떻게되는지 언급하지 않습니다. 사람들은 어쨌든 사람들이 이러한 예외를 명시 적으로 잡으려고 시도해서는 안되므로 유형을 문서화 할 필요가 없습니다.

전제 조건을 문서화하기 위해 명백한 내용을 명시하면 불필요한 혼란이 발생합니다. 메소드에 null을 전달하는 것이 명백한 의미가 없다면 호출자는 문서화되지 않은 경우에도 null을 전달하면 예외를 예상해야합니다. ObjectDisposedException의 경우에도 마찬가지입니다.이 인터페이스는 너무 널리 사용되어 Dispose를 호출하는 사람은 아무도 객체를 계속 사용하지 않을 책임을 인식합니다.

합리적인 경험 법칙 :

1. 고칠 수있는 예외를 잡아라.
2. 수정할 수 없지만 유용한 정보를 말할 수있는 예외를 잡아서 설명하고 다시 던지십시오.
3. 기본 처리보다 처리하거나 진단 할 수없는 예외를 포착하지 마십시오.

응용 프로그램이 넘어지지 않도록 아래에서 처리 할 수없는 모든 것을 포착하기 위해 최상위 수준의 치명적이지 않은 예외 처리기를 갖고 싶을 수도 있지만 특정 응용 프로그램에 크게 의존 할 것입니다. 예를 들어, iOS 애플리케이션은 가능한 한 많이 트래핑하는 것을 선호합니다. 거의 예외가없는 경우 명령 줄 앱이 완벽하게 작동 할 수 있습니다.

Java조차도 모든 예외를 "문서화"하지는 않습니다. 모든 thrown 개의 예외가 throws절 에서 언급되어야 한다는 요구 사항에도 불구하고 , 모든 코드 행은 RuntimeException메소드 서명에서 선언하지 않아도을 던질 수 있습니다 .

이를 수행하는 표준 방법은 Java 방식입니다. 프로그래밍 오류는 검사되지 않은 예외 여야하며 빠른 실패를 보장하기 위해 포착되지 않아야합니다. 계약 오류는 예외를 점검하며 클라이언트가 적절하게 처리해야합니다.