예외를 발생시키기 위해 보통 내장 예외 클래스 (예 : ArgumentNullException및)를 사용 NotSupportedException합니다. 그러나 때로는 사용자 정의 예외를 사용해야 하며이 경우 다음과 같이 씁니다.
class SlippedOnABananaException : Exception { }
class ChokedOnAnAppleException : Exception { }등등. 그런 다음 코드에서 던지고 잡습니다. 그러나 오늘 ApplicationException수업을 들었습니다. 대신 사용해야합니까? 그게 뭐야?
다른 이름을 가진 효과적으로 동일한 예외 클래스를 많이 갖는 것은 비효율적입니다 (일반적으로 개별 기능이 필요하지 않습니다). 그러나 나는 일반을 잡고 ApplicationException오류가 무엇인지 확인하기 위해 추가 코드를 사용해야 한다는 생각을 싫어합니다 .
ApplicationException내 코드와 어디에 맞아야합니까?
답변
msdn 의 설명 에 따르면 :
공용 언어 런타임이 아닌 사용자 응용 프로그램은 ApplicationException 클래스에서 파생 된 사용자 지정 예외를 발생시킵니다. ApplicationException 클래스는 응용 프로그램에서 정의한 예외와 시스템에서 정의한 예외를 구분합니다.
자체 예외를 작성해야하는 애플리케이션을 설계하는 경우 Exception 클래스에서 사용자 정의 예외를 파생시키는 것이 좋습니다. 원래 사용자 정의 예외는 ApplicationException 클래스에서 파생되어야한다고 생각되었습니다. 그러나 실제로 이것은 중요한 가치를 추가하는 것으로 밝혀지지 않았습니다. 자세한 내용은 예외 처리 모범 사례를 참조하십시오.
에서 파생 시키십시오 Exception. 또한, 귀하의 사례에 대해 새 예외를 생성하는 데 문제가있는 것으로 보이지 않습니다. 프레임 워크에 이미 예외가있는 경우에는이를 사용하고 그렇지 않으면 직접 롤백하십시오.
답변
짧은 대답은 어디에도 없습니다.
그것은 과거의 유물이며 Microsoft가 개발자가 ApplicationException에서 모든 사용자 정의 예외를 상속하도록 의도했습니다. 얼마 지나지 않아 그들은 마음이 바뀌었고 기본 예외 클래스에서 사용자 지정 예외를 파생시켜야한다고 조언했습니다. MSDN에서 예외 처리 에 대한 모범 사례를 참조하십시오 .
이에 대한 가장 널리 보급 된 이유 중 하나는 Jeffery Richter의 프레임 워크 디자인 지침 에서 발췌 한 것입니다 .
System.ApplicationException 은 .NET Framework의 일부가 아니어야하는 클래스입니다. 원래의 아이디어는 SystemException 에서 파생 된 클래스 는 CLR (또는 시스템) 자체에서 발생한 예외를 나타내지 만 CLR이 아닌 예외는 ApplicationException 에서 파생 된 것 입니다. 그러나 많은 예외 클래스가이 패턴을 따르지 않았습니다. 예를 들어, TargetInvocationException (CLR에서 발생)은 ApplicationException 에서 파생됩니다 . 따라서 ApplicationException 클래스는 모든 의미를 잃었습니다. 이 기본 클래스에서 파생 된 이유는 일부 코드가 기본 스택을 잡기 위해 호출 스택보다 높은 코드를 허용하기 때문입니다. 더 이상 모든 응용 프로그램 예외를 포착 할 수 없습니다.
그래서 당신은 그것을 가지고 있습니다. 집행 요약있는 ApplicationException이되지 않는 것입니다 유해한 그냥 쓸모 .
답변
.NET 1.0의 초기 디자인에서는 프레임 워크 자체가 발생 SystemException하여 파생 되도록 계획 되었습니다. 사용자 응용 프로그램-던지고 ApplicationException파생됩니다.
그러나 나중에 .NET 2.0에서는 삭제되었습니다.
따라서에서 파생됩니다 Exception.
