5장 - 4

예외 (Exception)

예외 발생시 CLR은 예외를 전파하는데

이 자체도 특정한 Type의 인스턴스이다.

이미 정의되어 있는 예외타입을 비롯하여 모든 예외는 관례상 다음 규칙을 따른다.

- 개발자가 정의하는 예외는 System.Exception을 상속받은 System.ApplicationException을 상속받는다.

- 접미사로 Exception을 클래스명에 추가한다.

- CLR에서 미리 정의된 예외는 System.SystemException을 상속받는다.

But 최근에는 개발자가 만드는 예외도 System.Exception을 상속받도록 권장하고 있는데

MS에서도 내부적으로 위의 관례를 따르지 않았기 때문이란다.

예외 처리

CLR은 예외 발생시 예외 처리기가 있을 경우 해당 예외 처리기로 예외를 넘기며,

그렇지 않다면 예외 메시지 출력 후 프로그램을 종료시킨다.

(이게 바로 Unhandled Exception...)

try, catch, finally

예외발생되어 catch로 가던 일반적으로 무사히 실행이 되던

finally 블록은 항상 실행이 보장된다.

(이 때문에 이 블록에 자원해제 같은 코드를 넣는게 권장...되기도)

별도의 예외 타입이 지정되지 않은 catch블록은 모든 예외를 잡을 수 있으나

특정 타입이 지정된 catch블록은 그 외의 다른 예외 발생시 예외 처리가 안되니 주의!

(다만 다중으로 catch블록 지정가능)

예외 발생

임의로 예외를 발생시키는 것도 가능

예외 타입의 인스턴스 생성 후 throw에 전달하면 됨.

AppliicationException ex = new ApplicationException("Invalid value");

throw ex;

catch블록 안에서도 throw가 가능하다.

다만 전달된 예외 인스턴스를 던지기 보다는

throw로만 끝내는게 낫다.

throw로만 사용한 경우 예외를 발생시킨 호출 스택이 모두 출력되기 때문.

예외 처리시 주의사항

1. public 메서드에 한해 인자값을 확인하고 올바르지 않으면 예외 발생

2. 예외를 범용적으로 catch하는 것은 스레드마다 하나만. 그 외에는 반드시 catch에 타입을 지정

3. 성능상 문제가 발생할 수 있는 경우 예외 처리가 없는 메서드를 제공.

4. try / finally 조합은 언제나 사용가능

스택

c++처럼 스택프레임이 아니라 쓰레드 생성시 기본 1mbyte (변경가능)이 할당되고 계속해서 사용된다.

다만 재귀호출을 반복하다보면 스택을 계속해서 소모하기 때문에 언젠가는 스택오버플로가 발생할 가능성이 생긴다.

힙

특별히 명시하지 않는 한 CLR에서는 managed heap을 가리킨다.

왜 managed?

GC가 할당/해제를 관장하니까.

Boxing

값 형식을 참조형식으로 변환

참조형식이므로, 힙 할당이 일어난다.

박싱이 빈번할 수록 힙 할당에 의한 GC활동이 늘어나고 그 때문에 성능은 떨어진다.

당연히 최대한 줄여야 하는데

BCL(Base Class Library)에서도 노력 중.

예를 들면 Console.WriteLine(...) -> 박싱 줄이려고 대부분의 기본제공타입을 모두 오버로딩.