안녕하세요? 홍환민입니다.

저도 예전에 정말 심각하리만큼.. 예외처리와 에러번호 리턴 방식에 대해 고민해 본 적이 있습니다.

에러번호 리턴 방식이란... int a(); 머 이런 함수를 둬서
리턴값이 0 이면 정상 완료이고.. -1 -2 머 이런거면 각각의 번호에 따라 어떤 에러인지를 뜻하는 것을
말하겠지요.

예외처리가 좋다는 큰 두가지 이유를 들자면..

첫번째는 함수 호출의 깊이가 깊어져서.. 저 깊숙히에서 예외가 발생해도.. 결국 얉은 곳까지 예외가 전달되어 온다는 것입니다.
물론 그 깊숙한 곳에서 이미 예외를 잘 처리해 주었다면 오지 않죠.

결론적으로 깊숙한 곳에 쳐박혀서 모르고 넘어갈 수도 있는 많은 에러나 예외를 개발자가 알 수 있도록 한다는 점에서
프로그램의 안정성 확보에 중요하다는 것입니다.

두번째는 코드의 간결함입니다. 동시에 에러처리가 아닌 로직 자체에 집중할 수 있음을 뜻합니다.

함수 A가 함수 B를 호출하고 함수 B가 함수 C를 호출한다고 했을때..
함수 C가 int 형의 에러코드를 반환하는 함수일 경우
함수 B, 함수 A도 에러코드를 반환하는 함수여야 할 것입니다.

그래야 결과적으로 함수 C를 호출한 함수 A가 어떤 에러가 발생한지 알수 있기 때문입니다.

물론 실무 코딩에서는 저렇게 에러코드를 일일이 다 검사해 주는 경우가 드문거 같습니다.
철저히 해서 다 검사해 주시는 분도 계시지만, 귀차니즘에 중요하지 않은 부분은 무시하지요.

위와 같은 상황을 봤을때 깊이들어가면 들어갈수록 에러 처리를 위한 코드는 산더미처럼 불어나게 됩니다.
그리고 에러 번호 관리에 따른 부하도 생겨나게 됩니다.

개발자 A가 만든 라이브러리 함수들이 있다고 합시다. 그리고 개발자 B가 만든 라이브러리 함수들이 있습니다.
팀장인 C가 A와 B가 만든 라이브러리 함수들을 내부적으로 호출하는 함수들을 만들었다고 합시다.

팀장 C의 함수에서 A와 B의 함수들을 각각 호출했을 때 에러코드이면 바로 그 에러코드를 리턴합니다.

int c()
{
  int a_result = a();
  if (a_result < 0) then  // 에러코드이면
    return a_result;

  int b_result = b();
  if (b_result < 0) then
    return b_result;
}

위와 같이 했을 때 개발자 A의 함수가 반환하는 에러코드와 B의 함수가 반환하는 에러코드는
그 에러코드 값의 대역이 달라와 할 것입니다.
A 함수는 -1000 ~ -2000 사이의 에러코드를 반환한다면 B 함수는 -2001 ~ -3000 사이의 에러코드를
반환한다... 라는 내부적인 규칙이 있어야 한다는 것이지요.

그리고 가장 큰 선입견이라고도 할 수 있는 부분이 있습니다.

예외처리하면 조금 에러만 나도 액세스 바이올레이션과 같은 치명적인 에러가 났다는 창이 화면에
뜬다는 것입니다. 실무에서는 고객에서 판매된 프로그램에서 그런 에러 화면이 나타나는것만큼 난감한게 없죠.

그런데 그런 예외 발생상황에서 메시지 박스가 뜨는 것이 예외처리에 대한 기본적은 처리 방식일 뿐입니다.
개발자가 특별히 예외 발생시 어떤 다른 동작을 한다고 하지 않았으면 메시지 박스를 띄워서 알려준다. 라는 것이지요.

이것은 Application->OnError 를 구현하되 내부가 비도록(아무 동작안하도록) 하면, 메시지 박스가 뜨는
것을 막을 수 있습니다.
그리고 OnError에서 파일에 로깅하도록 한다면, 프로그램에서 어떤 에러가 발생했는지를 일관적으로
로깅 할 수 있는 장점이 있기도 합니다.

그리고 마지막으로 장점 한가지를 더 언급하자면...
예외가 발생될때.. 기존 에러코드 반환 방식은 에러 코드만을 반환하는거에 반해서,
예외처리 방식은 클래스를 발생시킨다는 것입니다.

어떤 에러인가에서 부터 그 에러에 대한 구체적인 정보도 같이 실어서 발생시킬 수 있다는 것이지요.

이런 장점들이 있으므로, 기존의 에러코드 반환방식보다는 예외처리가 더 낫은 방식이라는 판단을 하게 되었습니다.

이제, 예외처리 방식의 단점을 말해보자면...

1. 어렵다. 여러가지 어려운 점이 있습니다. 예외를 발생시킬때 예외 클래스를 생성해서 발생시키는데
그 생성된 예외 클래스 인스턴스는 언제 파괴되느냐.. 에서부터 시작해서.. 예외 처리를 제대로 알려면
적지 않은 공부가 필요한 것도 사실입니다.
그리고 위에서 언급하였듯이 예외처리에 대해 잘 모르고, 편견을 가진 부분들이 존재하는 것도 사실입니다.

2. 디버깅시 번거롭다.
임프님이 언급하셨듯이 디버깅시 별로 중요하지 않은(자기가 디버깅하고 싶지도 않은) 부분에서 예외가
발생함으로서 그곳에서 실행이 멈추고, 메시지 박스가 뜨는 등.. 불편한 점이 있습니다.
이것의 해결 방법은 디버깅 옵션에서 설정이 가능합니다. 멈추지 않게 하는 방법이 있지요.
어쨋든 번거로운 부분들이 존재하는 것이 사실입니다.

3. 후킹 등의 시스템 로우 레벨 적인 부분에서 예외를 사용했을 경우 문제가 있다.
실무에서 후킹에서 예외를 발생시키게 설계하였을 경우.. 번거로운 부분도 있고,
프로그램이 뻗는 등의 문제가 있었습니다. 그 발생한 예외를 잘 처리해 주지 않고
무시한 경우가 특히 그랬던 것으로 생각되는데...

문제는 의식적으로 그런 경우에는 예외처리 방식을 쓰지 않으면 되는데..
문제는 라이브러리 형태로 사용하는 경우.. 예를 들어 화면 캡처 클래스를 예외처리 방식으로 만들었는데
후킹 루틴 내에서 캡처 클래스를 사용했을 경우처럼.. 그런 문제들이 존재하지요.

이만 줄입니다.
행복하세요.



조해진 님이 쓰신 글 :
: 일반적으로 제공해 주는 언어의 예외 처리기능을
:
: 
:
: "도데체 어디다  쓰나?"  라는 생각을 해왔습니다
:
: 
:
: 
:
: 또한 함수의 리턴값 만으로 충분히 예외 상황을 처리할수 있다고 생각해 오면서 
:
: 
:
: "예외 처리 기능을 쓰는건 불필요한 오버헤드만 증가 시킬뿐이다"  라고  자위하고 있었습니다
:
: 
:
: 
:
: 하지만......  불가피하게  함수의 함수 속 깊숙이 들어가  에러를 리턴 받으려면
:
: 
:
: 받아오는 절차가 함수 깊이 만큼 되더랍니다 -_-;
:
: 
:
: 
:
: 이렇게 프로그래밍 하면 안되겠다 싶어서  함수의 함수 깊은속 까지 들어가 에러값을 받아오는 경우라면
:
: 
:
: 예외를 발생 시키는 편이 좋을거 같다는 생각이 들더군요
:
: 
:
: 이거 심각하게 고민하다가 갑자기 떠오르는 방안이었습니다
:
: 
:
: 
:
: exceptional c++ 책에보면  예외 처리를 생각한 구조라면 설계때부터  그런식으로 만들어야 한다고 하더군요
:
: 
:
: 맞는 말 같기도 한데.....   언어의 예외처리기능, 볼랜드 회원님들은 어떤식으로 사용하는지 궁금하네요
:
: