예외 발생

이 섹션에 설명된 예외 throw 지침에는 실행 실패의 의미에 대한 적절한 정의가 필요합니다. 실행 실패는 멤버가 수행하도록 디자인된 작업을 수행할 수 없을 때마다 발생합니다(멤버 이름이 의미하는 바). 예를 들어 메서드가 OpenFile 열린 파일 핸들을 호출자에게 반환할 수 없는 경우 실행 실패로 간주됩니다.

대부분의 개발자는 0으로 나누기 또는 null 참조와 같은 사용 오류에 대한 예외를 사용하는 것에 익숙해집니다. 프레임워크에서 예외는 실행 오류를 포함하여 모든 오류 조건에 사용됩니다.

❌ 오류 코드를 반환하지 마세요.

예외는 프레임워크에서 오류를 보고하는 기본 수단입니다.

✔️ 예외를 던져 실행 오류를 보고하세요.

✔️ 코드가 추가 실행을 위해 안전하지 않은 상황에 직면하면 예외를 throw하는 대신 System.Environment.FailFast를 호출하여 프로세스를 종료하는 것이 (.NET Framework 2.0 기능)입니다.

❌ 가능한 경우 일반적인 제어 흐름에 예외를 사용하지 마세요.

시스템 오류 및 잠재적인 경합 조건이 있는 작업을 제외하고 프레임워크 디자이너는 사용자가 예외를 throw하지 않는 코드를 작성할 수 있도록 API를 디자인해야 합니다. 예를 들어 사용자가 예외를 throw하지 않는 코드를 작성할 수 있도록 멤버를 호출하기 전에 사전 조건을 확인하는 방법을 제공할 수 있습니다.

다른 멤버의 사전 조건을 확인하는 데 사용되는 멤버를 테스터라고도 하며 실제로 작업을 수행하는 멤버를 doer라고 합니다.

Tester-Doer 패턴에 허용할 수 없는 성능 오버헤드가 있을 수 있는 경우가 있습니다. 이러한 경우 소위 Try-Parse 패턴을 고려해야 합니다(자세한 내용은 예외 및 성능 참조).

✔️ 예외를 throw할 때 성능에 미치는 영향을 고려하세요. 초당 100개를 초과하는 throw 속도는 대부분의 애플리케이션의 성능에 눈에 띄게 영향을 미칠 수 있습니다.

✔️ 시스템 오류가 아닌 멤버 계약 위반으로 인해 공개적으로 호출 가능한 멤버가 throw한 모든 예외를 문서화하고 계약의 일부로 처리합니다.

계약의 일부인 예외는 한 버전에서 다음 버전으로 변경해서는 안 됩니다(예: 예외 형식은 변경되지 않아야 하며 새 예외를 추가해서는 안 됨).

❌ 일부 옵션에 따라 throw하거나 throw할 수 없는 공용 멤버가 없습니다.

❌ 예외를 반환 값 또는 매개 변수로 반환하는 공용 멤버가 out 없습니다.

예외를 throw하는 대신 공용 API에서 예외를 반환하면 예외 기반 오류 보고의 많은 이점이 무효화됩니다.

✔️ 예외 작성기 메서드를 사용하는 것이 좋습니다.

다른 위치에서 동일한 예외를 던지는 것이 흔합니다. 코드가 부풀어 오르지 않도록 하려면 예외를 만들고 해당 속성을 초기화하는 도우미 메서드를 사용합니다.

또한 예외를 throw하는 멤버는 인라인되지 않습니다. 작성기 내에서 throw 문을 이동하면 멤버를 인라인 처리할 수 있습니다.

❌ 예외 필터 블록에서 예외를 throw하지 마세요.

예외 필터가 예외를 발생시키면, CLR에 의해 예외가 포착되고 필터는 false를 반환합니다. 이 동작은 명시적으로 false를 실행하고 반환하는 필터와 구별할 수 되므로 디버그하기가 매우 어렵습니다.

❌ 최종 블록에서 예외를 명시적으로 throw하지 마세요. throw하는 메서드를 호출하여 발생하는 암시적으로 throw된 예외는 허용됩니다.

Microsoft Corporation의 일부 저작권 2005, 2009. 모든 권리 보유.

프레임워크 디자인 지침에서 Pearson Education, Inc.의 권한으로 재인쇄 : 재사용 가능한 .NET 라이브러리에 대한 규칙, 관용구 및 패턴, Krzysztof Cwalina 및 Brad Abrams의 제2판, Microsoft Windows 개발 시리즈의 일환으로 Addison-Wesley Professional이 2008년 10월 22일 출판했습니다.

참고하십시오

• 프레임워크 디자인 지침
• 예외에 대한 디자인 지침