내 응용 프로그램에서 발생할 수있는 기본 제공 .NET 예외는 무엇입니까?

내 응용 프로그램에서 발생할 수있는 기본 제공 .NET 예외는 무엇입니까?

---

내 응용 프로그램에서 예외를 throw해야하는 경우 기본 제공 .NET 예외 클래스 중 어떤 것을 사용할 수 있습니까? 모두 공정한 게임입니까? 언제 내 자신을 파생해야합니까?

---

예외 생성 및 던지기를 참조하십시오 .

내장 예외를 던질 때 다음과 같이 말합니다.

고유 한 소스 코드에서 의도적으로 System.Exception, System.SystemException, System.NullReferenceException 또는 System.IndexOutOfRangeException을 throw하지 마십시오.

과

일반적인 예외를 던지지 마십시오

라이브러리 또는 프레임 워크에서 Exception 또는 SystemException과 같은 일반 예외 유형을 throw하면 소비자가 처리 방법을 모르는 알 수없는 예외를 포함하여 모든 예외를 포착하도록합니다.

대신 프레임 워크에 이미 존재하는 더 많은 파생 형식을 던지거나 Exception에서 파생되는 고유 한 형식을 만듭니다. "

이 블로그 항목 에는 몇 가지 유용한 지침도 있습니다.

또한 FxCop 코드 분석은 여기에 설명 된대로 "예외를 발생시키지 않음"목록을 정의합니다 . 다음을 권장합니다.

다음 예외 유형은 사용자에게 충분한 정보를 제공하기에는 너무 일반적입니다.

• System.Exception
• System.ApplicationException
• System.SystemException

다음 예외 유형은 예약되어 있으며 공용 언어 런타임에서만 throw되어야합니다.

• System.ExecutionEngineException
• System.IndexOutOfRangeException
• System.NullReferenceException
• System.OutOfMemoryException

따라서 이론적으로는 Microsoft에서 설명한대로 예외의 의도를 명확하게 이해하면 다른 프레임 워크 예외 유형을 발생시킬 수 있습니다 (MSDN 문서 참조).

이것들은 "지침"이며 다른 사람들이 말했듯이 System.IndexOutOfRangeException에 대한 논쟁이 있습니다 (즉, 많은 개발자들이이 예외를 던집니다).

---

System.Exceptionand 의 주제에 대해 System.ApplicationException: 후자는 모든 사용자 정의 예외의 기본 클래스로 사용되도록 의도되었습니다. 그러나 이것은 처음부터 일관되게 시행되지 않았습니다. 결과적으로이 System.Exception클래스를 모든 예외에 대한 기본 클래스로 사용하지 않고 전혀 사용해야하는지 여부에 대한 논란이 있습니다 .

어떤 방식으로 결정하든 이 두 클래스의 인스턴스를 직접 던지지 마십시오 . 실제로 그들이 그렇지 않다는 것은 유감입니다 abstact. 그만한 가치를 위해 항상 가능한 가장 구체적인 예외를 사용하십시오. 요구 사항을 충족 할 수있는 것이 없으면 자유롭게 직접 만들 수 있습니다. 그러나이 경우 예외가 기존 예외보다 이점이 있는지 확인하십시오. 특히 의미를 완벽하게 전달하고 상황을 의미있게 처리하는 데 필요한 모든 정보를 제공해야합니다.

의미있는 작업을 수행하지 않는 스텁 예외를 생성하지 마십시오. 같은 맥락에서 거대한 예외 클래스 계층 구조를 만들지 마십시오. 거의 유용하지 않습니다 (비록 사용하는 상황을 상상할 수 있지만 파서가 그중 하나입니다).

---

나는 ArgumentException(그리고 그“친구”)를 정기적으로 사용합니다.

NotSupportedException그리고 NotImplementedException또한 일반적입니다.

---

내 조언은 두 가지에 초점을 맞추는 것입니다.

1. 시나리오
2. 사용자 기대

다른 말로하면, 나는 앉아서 다음을 식별 할 것입니다.

1. 어떤 시나리오에서 예외를 던지고 싶습니까?
2. 이러한 시나리오에서 API 사용자는 무엇을 기대할까요?

1 번에 대한 답은 물론 애플리케이션에 따라 다릅니다. # 2에 대한 대답은 "이미 익숙한 유사한 코드가 수행하는 작업"입니다.

이로 인해 발생하는 동작은 다음과 같습니다.

1. 인수가 null이거나, 범위를 벗어 났거나, 유효하지 않거나, 메서드가 구현되지 않거나, 지원되지 않는 것과 같이 프레임 워크 내부에도 도착하는 프로그램에서 발생하는 시나리오에서 프레임 워크가 사용하는 것과 동일한 예외를 사용해야합니다. API를 사용하는 사람들은 (다른 모든 것이 작동하는 방식이기 때문에) 그런 방식으로 행동하기를 기대할 것이며, 따라서 "시작"에서 API를 더 잘 사용할 수있을 것입니다.

   2. 프레임 워크에 존재하지 않는 새로운 시나리오의 경우 계속해서 고유 한 예외 클래스를 만들어야합니다. 필요한 서비스를 제공하는 다른 기본 예외가 아니라면 Exception을 기본 클래스로 선호해야한다고 말하고 싶습니다. 일반적으로 "ApplicationException"과 같은 것이 도움이되지 않는다고 생각합니다. 고유 한 예외를 정의하기 시작할 때 염두에 두어야 할 몇 가지 사항이 있습니다.

   ㅏ. 예외의 주요 목적은 사람과의 의사 소통입니다. 가져서는 안되는 일에 대한 정보를 전달합니다. 문제의 원인을 파악하고 해결 방법을 파악할 수있는 충분한 정보를 제공해야합니다.

   비. 내부 일관성은 매우 중요합니다. 비슷한 상황에서 앱이 최대한 보편적으로 작동하도록하면 API 사용자의 생산성이 향상됩니다.

당신이해야 할 일과하지 말아야 할 일에 대한 엄격하고 빠른 규칙이있는 한 .. 그 일에 대해서는 걱정하지 않을 것입니다. 대신 시나리오를 식별하고 해당 시나리오에 맞는 기존 예외를 찾은 다음 기존 예외가없는 경우 신중하게 결정하는 데 집중합니다.

---

당신은 그들 중 거의 모든 것을 만들고 던질 수 있지만 일반적으로 그렇게해서는 안됩니다. 예를 들어 다양한 인수 유효성 검사 예외 (ArgumentException, ArgumentNullException, ArgumentOutOfRangeException 등)는 응용 프로그램 코드에서 사용하기에 적합하지만 AccessViolationException은 그렇지 않습니다. ApplicationException은 필요한 사용자 지정 예외 클래스에 적합한 기본 클래스로 제공됩니다.

모범 사례 목록은 이 MSDN 문서 를 참조하십시오. 예외 처리를 참조하지만 예외 생성에 대한 좋은 조언도 포함되어 있습니다.

참고 URL : https://stackoverflow.com/questions/218150/which-built-in-net-exceptions-can-i-throw-from-my-application