추상 예외 슈퍼 타입

던지기 System.Exception가 그렇게 나쁘다고 여겨 지면 왜 처음부터 Exception만들어 지지 않았 abstract습니까?

그렇게하면 전화를 걸 수 없습니다.

throw new Exception("Error occurred.");

이렇게하면 파생 된 예외를 사용하여 발생한 오류에 대한 자세한 정보가 제공됩니다.

예를 들어 라이브러리에 사용자 정의 예외 계층을 제공하려는 경우 일반적으로 예외에 대한 추상 기본 클래스를 선언합니다.

public abstract class CustomExceptionBase : Exception
{
    /* some stuff here */
}

그리고 더 구체적인 목적을 가진 일부 파생 예외가 있습니다.

public class DerivedCustomException : CustomExceptionBase
{
    /* some more specific stuff here */
}

그런 다음 라이브러리 메소드를 호출 할 때 라이브러리에서 오는 오류를 직접 잡기 위해이 일반적인 try / catch 블록을 가질 수 있습니다.

try
{
    /* library calls here */
}
catch (CustomExceptionBase ex)
{
    /* exception handling */
}

이것이 좋은 습관입니까?

Exception추상적이게 되면 좋을까요?

편집 : 내 요점은 예외 클래스가 표시 abstract되어도 여전히 모든 블록에서 잡을 수 있다는 것입니다. 이를 추상화하는 것은 프로그래머가 "슈퍼 와이드"예외를 던지지 못하게하는 방법 일뿐입니다. 일반적으로 자발적으로 예외를 던질 때 어떤 유형과 예외가 발생했는지 알아야합니다. 따라서 좀 더 구체적인 예외 유형을 던져야합니다.

나는 이것이 왜 이런 식으로 수행되었는지 실제 이유를 알지 못하고, 특정 범위까지 무한한 넓은 예외가 발생하는 것을 방지하는 것이 좋습니다.

그러나 작은 데모 응용 프로그램이나 개념 증명을 코딩 할 때 10 가지 예외 하위 클래스 디자인을 시작하거나 상황에 가장 적합한 예외 클래스를 결정하기 위해 시간을 보내고 싶지 않습니다. 오히려 Exception세부 사항을 설명하는 문자열을 던져서 전달 하고 싶습니다 . 내가 한 경우 던져 - 멀리 코드, 나는 이러한 것들에 대해 걱정하지 않을 경우 강제로 그런 것들에 대해 신경, 나도 내 자신의 만들 것 GenericException수업을하고 던져 그 모든 곳에서, 또는 다른 도구 / 언어로 이동합니다. 일부 프로젝트의 경우 관련 예외 서브 클래스를 올바르게 작성하는 것이 중요하지만 모든 프로젝트에서이를 요구하는 것은 아닙니다.

가능성 A : 논리적으로 맞습니다.

Microsoft는 다른 많은 사람들과 함께 수많은 new Exception()이유로 직접 던지기를 제안하지 않는 것이 맞습니다 .

즉, Exception클래스 계층 구조 의 목적은 가장 구체적인 예외 만 포착 할 수 있도록 축소 효과를 정의하는 것이라는 학문적 이상을 고려할 수 있습니다. (즉, ArgumentNullException보다 좁습니다 ArgumentException).

Exception 클래스는 예외가 아닙니다 (pun 의도하지 않음). 범위가 무한히 넓기 때문에 거의 포착 할 수없는 "슈퍼 예외"인 가장 넓은 예외입니다. '예외' abstract예외는 그 자체로 엔티티로서 존재할 수 없다는 의미 가 아닙니다 . 좋은 사례는 아직 정의되지 않았지만 가능성 B 참조), 공개적으로 구성 가능해야한다.

'추상적 인'키워드 (순전히 학문적 의미에서)는 기본 수업 자체가 이해가되지 않는 경우에만 적용 할 수 FourLeggedAnimal있습니다.

마음이 모든, 아니있을 것입니다 기술 클래스를 만드는 이유는 abstract, 개발자 악화의 원인이 될 수있는 것보다 다른 .

가능성 B : 디자인 잠금 / 몰랐다

만약 MS가이 수업을 추상적으로 만들었다면, 언어의 기본에 매우 중요하기 때문에 길을 가다듬었다면 어려움에 처했을 수도 있습니다. 그들은 이미으로 구부러 졌으므로 ApplicationException길을 따라 권장 사항이 변경 될 것으로 예상됩니다. ( http://blogs.msdn.com/b/kcwalina/archive/2006/06/23/644822.aspx 참조 )

다른 이유가있을 수 있습니다 (Reflection 또는 다른 기술적 인 이유와 관련이 있다고 생각합니다).이 게시물을 CW로 만들고 있습니다.