예외 클래스 : C# (.Net)에서 파생시킬 때?

Question

나는 나의 시험 개정을 계속하고있다.

나는 Base Exception 클래스의 사용법을 보았고 시험 논문에서도이 코드를 보았습니다.

내 질문은 기본 예외 클래스에서 언제 파생됩니까?

사용자 지정 클래스에서보다 의미있는 정보로 예외를 throw하려는 경우 사용자 지정 클래스가 사용되는 방식을 나타내는 정확한 데이터가 포함 된 사용자 지정 예외 클래스를 만들 수 있습니다. 어떤 시나리오가 사용되도록 고안 되었습니까?

내 맞춤 예외 클래스가 'ApplicationException'또는 'SecurityException'또는 기본 'Exception'클래스에서 파생되지 않는 이유는 무엇입니까?

저는 이전의 두 클래스가 아니라 기본 Exception 클래스에서 파생되어야한다는 인상을 받았습니다.

제 질문은 두 번째입니다. 다른 두 개에서 언제 파생됩니까? 이 세 가지 중 하나에서 언제 파생 될 것인지에 대한 명확한 정의가 있습니다 ( )? 다른 사람들이 없다고 가정하면 나는 빠져 나왔습니다.

작은 UPDATE : 트랜 센더에서이

이 질문은 꽤 많이 머리에 못을 안타.

---

* 애플리케이션 별 예외를 생성하는 데 사용해야하는 클래스는 무엇입니까?

답변 :

Answer 1

이 모든 Design Guidelines 문서에서 설명 *있는 ApplicationException 클래스입니다.

Answer 2

일반적으로 던져 넣을 예외 유형과 가장 유사한 Exception 클래스에서 파생되기를 원합니다. 문제를 유발하는 Argument 또는 Parameter가 전달 된 것이 문제라면 ArgumentException을 사용하십시오. 이를 사용하여 사용자 정의가 필요한 경우 ArgumentException을 상속합니다.

기본 예외를 사용하는 유일한 두 가지 이유는 다음과 같습니다. 1) 현재 예외 모델 중 하나에 맞지 않는 사용자 지정 예외가 필요하거나 2) 이론적으로 여러 가지 메서드를 throw 할 수있는 경우 예외는 있지만 이미 던져 질 가능성이 가장 높은 것을 발견했습니다.

일반적으로 나는 예외로부터 상속받지 않습니다. Message 속성을 설정하기 만하면됩니다.

Answer 3

가장 최근의 프로젝트에서는 기본 예외 클래스를 사용했습니다. 그래서 함께

같은 방식으로 포맷하는 데 필요한 모든 예외 메시지를 기본 클래스에서 수행 된 수에 대한 속성을 정의

• 모든 예외 번호를 필요 : 우리는 다음과 같은 기능을 얻기 위해 그것을 사용 번호, 이유 및 유형. 이것은 formmated 메시지가 기본 클래스에서 수행되었습니다.

우리의 기본 예외 클래스는 ApplicationException에서 파생됩니다. 이것은 실수 일 수도 있습니다. 너무 많은 상속의 문제에 대한 논의가 많이 있습니다. 그러나 우리는이 문제에 아무런 문제가 없었습니다.

시험에 대한 팁 : 질문을 매우 자세히 읽어보십시오. 행운을 빕니다.

Answer 4

예외적으로 예외는 여러 가지 예외를 동일한 방식으로 처리하려는 경우 모두 공통 기본 클래스에서 파생 될 수 있도록 계층 구조로 그룹화되어야합니다. 기본 던지기 가능 유형이 클래스가 아닌 인터페이스 인 경우, 그러한 이상은 다소 달성 가능할 수 있습니다. 그러나 클래스의 단일 상속 제한은 계층의 유용성을 심각하게 제한합니다.

예외 계층 구조가 유용한 개념 일 수있는 유일한 경우는 인터페이스의 구현 또는 특정 예외를 throw하는 것으로 문서화 된 새 버전의 클래스가 코드가보다 명확한 조건 그 예외에 의해보고 된 것보다. 그러한 시나리오에서, 예외를 던져서 문서화 된 것들로부터 파생되지 않는 예외를 던지는 것은 급격한 변화가 될 것이므로 이전에 예기치 않은 상태를 가장 잘 설명하는 문서화 된 것을 상속 한 예외를 던져야합니다. 오히려 못생긴 일이지만, 예외 처리 메커니즘은 실제로 더 나은 대안을 제공하지 않습니다. IEnumerator<T>.MoveNext()과 같은 것들이 단순히 "미안하다 - 시스템에 불이 나거나 아무것도 아니며 아무도 컬렉션을 변경하지 않았다는 것을 알지 못한다. 예외를 던지는 것으로 문서화되어 있지 않다. 다음 항목으로 가거나 정직하게 열거가 완료되었다고 말하면서 "그러나 그들은 그렇지 않습니다.

기존 코드와 호환되는 예외를 throw해야하는 경우를 제외하고 응용 프로그램 또는 라이브러리에서 사용하는 예외를 공통 기본에서 파생시키는 것이 도움이 될 수 있습니다. ApplicationException을 사용하는 대신 YourApplicationNameException 또는 YourLibraryNameException과 같은 형식이어야합니다. 그 밖의 것은 얻을 수없는 것이어야합니다. catch ApplicationException을 수행하는 코드는 해당 유형에서 파생 된 예외뿐만 아니라 다른 라이브러리에서 파생 된 예외도 가져올 수 있기 때문에 ApplicationException과 같은 점은 좋지 않습니다.