.NET 의 일반적인 예외 와 System.Exception 타입

일반적인 예외 형식

예외 형식	설명	예제
Exception	모든 예외의 기본 클래스.	없음(이 예외의 파생된 클래스 사용).
IndexOutOfRangeException	배열이 올바르지 않게 인덱싱된 경우에만 런타임에서 발생됩니다.	유효 범위를 벗어난 배열 인덱싱: arr[arr.Length+1]
NullReferenceException	null 개체가 참조되는 경우에만 런타임에서 발생	object o = null; o.ToString();
InvalidOperationException	잘못된 상태에 있는 경우에 메서드에서 발생	기본 컬렉션에서 항목을 제거한 후 Enumerator.MoveNext() 호출.
ArgumentException	모든 인수 예외에 대한 기본 클래스.	없음(이 예외의 파생된 클래스 사용).
ArgumentNullException	인수에 Null을 허용하지 않는 메서드에서 발생	String s = null; "Calculate".IndexOf(s);
ArgumentOutOfRangeException	인수가 지정된 범위에 있는지 확인하는 메서드에서 발생	String s = "string"; s.Substring(s.Length+1);

---

 

System.Exception 타입
예외 형식

속성	접근	타입	설명
Message	읽기 전용	String	애외가 발생한 이유를 설명한 텍스트를 포함하고 있다. 이러한 메시지는 예외가 처리되지 않을 경우에 로그상에 기록되는 내용이다. 일반 사용자의 경우 이러한 메시지를 드려다 볼 경우가 없기 때문에 최대한 기술적인 관점에서 메시지가 작성되어 개발자가 로그를 살펴보고 다음 버전에 문제를 해결 할 수 있도록 세부적인 정보들을 포함해야 한다.
Data	읽기 전용	IDictionary	키-값 쌍의 컬렉션에 대한 참조를 담고 있다. 보통 예외를 발 생시킨 코드에서 예외 발생 직전에 이 컬렉션에 항목들을 포 함시킨다. 예외를 잡은 코드는 이 컬렉션 내의 항목들을 살펴 서 예외 복구 과정에 활용할 수 있다.
Source	읽기/쓰기	String	예외를 발생시킨 어셈블리의 이름을 가지고 있다.
StackTrace	읽기 전용	String	예외가 발생된 원인을 찾기 위한 실마리를 제공하기 위하여 호출된 메서드들의 이름과 원형이 저장되어 있다. 디버깅 시 에 상당히 귀중한 정보가 된다.
TargetSite	읽기 전용	MethodBase	예외를 발생시킨 메서드의 이름을 가지고 있다.
HelpLink	읽기 전용	String	발생한 예외가 무엇인지 사용자가 이해할 수 있도록, 제공 되는 문서의 URL 정보를 가지고 있다(C: \MyApp\Help. htm#MyExceptionHelp과 같이). 안정적으로 프로그래밍 을 유지하고 보안을 유지하기 위해서라도 처리되지 않은 예 외의 기초 정보를 사용자가 살펴보도록 허용하는 것은 좋은 방법이 아니다. 이로 인해 특별히 다른 개발자에게 전달해줄 만한 주요 정보 가 있는 경우가 아니라면 이 속성의 거의 사용되지 않는다.
Inner Exception	읽기 전용	Exception	현재 발생한 예외가 다른 예외를 처리 중에 새롭게 발생한 예 외인 경우, 이전에 발생한 예외를 담고 있다. 읽기 전용이며, 보통 null이다. public GetBaseExcept ion 메서드를 이 용하면 Inner Exception으로 이어진 연결 리스트를 타고 들어가 가장 최초에 발생한 예외가 무엇인지를 얻을 수 있다.
HResult	읽기/쓰기	Int32	이 32비트 값은 관리 코드와 비관리 코드의 경계를 넘나 들 때 사용되는 값이다. 예를 들어 COM API가 실패 값으로 HRESULT를 반환하면, CLR은 Exception 계통의 객체의 이 속성에 반환 값을 저장한다.

예외를 어떻게 사용하는 것이 좋은지에 대해서 올바른 교육을 받지 못한 개발자들이 정말 광범위 하게 저지르고 있는 실수 중에 하나가 바로 너무 자주 catch 블록을 사용한다는 것과,올바르지 않게 catch 블록을 사용한 다는 것이다.

예외를 잡을 때에는 먼저 예외를 잡아서 무엇을 할지,그러한 예외가 왜 발생하는지, 그리고 어떻게 발생한 예외를 다루어야 할지를 먼저 알아야 한다.

 

다른 말로 하자면, 용용프로그램을 정책을 정해야 한다는 것이다.

다음과 같은 코드를 너무 자주 보게 된다.

try{
／／ 개발자가 실패할 것을 염두에 둔 코드를 여기서 수행한다.
catch (Exception) {
        ....
        }
    }​

 

이코드는 어떤 상황에서 어떤한 예의가 발생하더라도 그 상황을 극복할 수 있는 방법을 모두 안고 있는 것처림 보인다. 이게가능하겠는가? 클래스 라이브러리의 일부로 제공되는 타입은 절대로,결코,어떤 상황에서도 모든 예외를 이처럼 잡아 없애버려서는 안 된다.

 

예외를 발생시키는 메서드를 작성할 때는 항상 예외를 유발하는 조건을 사전에 검사할 수 있는 메서드를 함께 작성할 것을 권장한다. 

만약..

오류가 발생했음을 무시한다면 데이터가손상된 상태로 응용프로그램이 수행될 것인데 이 경우 정상적으로 수행을 이어가기 어립다.

오류가 발생했음을 알리는 수단으로 예외를 사용하기로 결정했다 하더라도 항상 예외를 통해 오류를 보고해야 하는 것은 아니다. 

즉, 모든 오류 상황을 예외로 다룰 필요는 없다.