ANMIAN

에러 처리하기

에러를 처리하기 전에 알아야 하는 것들:
* 에러가 어디서 나왔는가
* 당신을 무엇을 하려 했는가(무엇을 하다가 에러가 발생했는가)
* 일이 왜 잘못 되었나
* 에러가 언제 일어났나
* 에러의 심각성
* 에러를 고치는 방법

에러를 발견했을 때
1. logging (로그기록)
2. report(보고) (임베디드의 경우 보고대신 스스로 처리해야 할 때도 있다)
3. recovery(복구)
3. ignore(무시)
4. propagate(전파) : # 똑같은 에러정보를 전파, # 재해석 후 새로운 메시지를 전파

코드구현 테크닉

오류의 발생은 원인에 따라 세가지로 요약할 수 있다.
사용자 에러 : 정확히 다 잡기가 어려워 배포 후에도 발생할 수 있다.
프로그래머 에러 : 나와서는 안되는 에러
예외상황 : 프로그래머가 정상적으로 작성했고 사용자도 정상적으로 사용했다. 하지만 네트워크 연결이 이상할 수도 있고, 하드디스크나 메모리에 용량이 부족할 수도 있고 갑자기 전원이 나갈 수도 있다.

에러를 처리하는데 중요한 몇가지를 먼저 알아보자.
1. 발생은 하위 콤포넌트, 처리는 호출자(caller) : 즉 누군가 일을 잘못하면 시킨 사람이 책임진다는 뜻이다.
2. 잘못이 있을 때는 에러를 발생시켜야 한다.(그냥 뻗도록 해서는 안된다.)
3. 보고도리 수 있는 모든 에러를 감지한다.
4. 감지된 에러를 적절하게 처리한다.
5. 처리할 수 없는 에러는 다른 곳으로 전파한다.
에러 처리는 exception 처리와 거의 같게 취급하면 될 것 같다.

에러 리포트 메커니즘 ( 오류를 알리기 위한 방법 )
1. return값 : return되는 값이 boolean으로 함수의 성공, 실패를 알려주는 용도라면 적당하게 작동한다. 단, 에러의 종류는 알 수 없다. return 값이 필요한 함수에서 오류도 함께 return의 값으로 알려주려고 시도하는 경우도 있다. 가능은 하지만 권장하지 않는다. 그래도 꼭 해야 하겠다면 몇가지 방법이 있다.
  * return값을 좀더 복잡하게 만들어 원하는 결과와 오류정보를 둘다 가지고 있는 구조체나 객체를 return하는 방법 : 네트워크에선 가끔 이용되지만 일반적인 프로그래밍에선 사용되는 경우가 거의 없다.
  * 참조(reference)를 이용하여 파라미터를 통해 보내는 방법 : 이또한 보기에도 좋지 않고 직관적이지도 않다.
  * 오류의 범위를 지정 : return값이 0이상의 값만 의미가 있을 때(count등) 음수를 오류로 처리하거나 참조나 포인터일 경우 NULL을 에러로 처리하는 것이 가능하다.
어떤 방법을 사용하건 지저분해진다. 에러를 발생시키는 것도 어렵지만 처리도 지저분해진다.

2. 에러 상태 변수 : 특수한 값들을 에러로 define해놓는 방법이다. C언어에서 가끔 사용되는데 결국 이런 것도 전역으로 사용되며 프로그램이 실행되는 동안 내내 메모리에 올라가 있는 값이기 때문에 많으면 좋지 않다. 게다가 파일이 여러개면 제대로 확인하기도 어렵다.

3. exception(예외처리)
에러처리를 위해 만들어진 구문으로 throw-catch, throws구문을 이용하여 에러를 handler에게 보내는 방법이다. 에러처리 전문 문법이기 때문에 가장 깔끔하고 직관적이지만 모든 언어에서 지원해주는 것은 아니다. C언어에는 없고, C++, JAVA, .NET등에는 있다.
 * 종결모델(termination model) : 헨들러가 처리한 부분부터 다시 실행(C++, .NET, JAVA)
 * 재개모델(resumption model) : 오류가 발생한 부분으로 돌아가서 다시 실행
예외처리는 안전성에 몇가지 단계가 있다.
==== 기초보장(basic guarantee)
   exception이 발생해도 메모리 누수가 없도록 해야한다. 동적 할당을 받았다면 반드시 확인해보자.
==== 강력한 보장(strong guarantee)
   exception이 발생해도 프로그램의 상태는 아무것도 바뀌면 안된다. 전역변수도, 지역변수도 객체도 그 값을 그대로 유지하고 있어야 한다.
==== no throw(nothrow guarantee)
   operation이 exception을 던질 수 없도록 만든다. 3가지 보장 중 가장 강력한 방침인데 예외상황을 발생시키지 않는다. 가장 중요한 것은 소멸자에서 exception을 던지지 않는다는 보장이 있어야 한다는 것인데 객체지향언어에서 소멸자는 객체의 생명이 다할 때 자동으로 호출되며 exception이 발생했을 때도 스택이 풀리면서 호출된다. (C#에서는 소멸자에서 exception을 던지는 것이 의미가 있으며 그것을 인정한다)

4. signal
극단적인 에러 리포트 메커니즘으로 전기 신호로 에러를 발생시키고 시그널 핸들러를 설치해야 한다.

=======================================================================
exception을 무시하더라도 감지하는 코드는 만들어둬야 한다.
그래야 나중에 코드를 봤을 때 exception의 가능성이 있다는 것을 알 수 있다.
=======================================================================

일관성
코멘트도 일관성을 유지하는 것이 좋다. 보기 좋은 떡을 만들라. 누가 뭐래도 코멘트는 사람에게 보여주기 위해 작성하는 것이 아닌가!

뚜렷한 블록 코멘트
에디터에서 색이 다르고 굵게 표시되는 경우가 많지만 흑백으로 프린트해서 봐야 할 수도 있다.(특수한 경우를 생각하지 말고 일반적인 것을 생각하라!)
코멘트의 시작과 끝은 들여쓰기 등으로 다른부분과 구분을 지어야 한다.

/*
  * 좋은 예시의
  * 블록 코멘트
  * 알아보기가 쉽다.
*/

/* 나쁜 예시의
          블록 코멘트
알아보기 어렵다.
*/

1행 코멘트
코드 중간에 들어가지 않도록 해야 한다. 만약 코드 중간에 한줄을 잡는다면
코드의 들여쓰기와 맞춰 알아보기 쉽도록 해야한다.
행 끝에 따로 띄어서 코멘트를 작성하는 것도 괜찮다.
오른쪽에 코드로부터 분리하여 코멘트들을 작성하는 것인데 알아보기는 쉬우나 코드를 수정할 때 간격을 다시 맞춰야 하고 코드가 긴 행을 만나면 화면 밖으로 나가버릴 가능성도 있다.

일반적인 약속(관례)
코멘트는 코드의 위쪽에 쓰인다. 즉, 코멘트가 먼저 나오고 그에 해당하는 코드가 나온다.
코멘트가 단락의 시작으로 여겨지도록 한다.

유지보수가 저렴한 스타일을 선택
/***********************************
*******     모양은 이쁘지만    ********
*******  간격맞추기가 어렵다  ********
***********************************/
게다가 스페이스를 사용하느냐 탭을 사용하느냐에 따라 모양이 다르고 탭을 사용하는 경우 탭의 너비설정이 다르면 또 모양이 달라진다. 쓸데없는 곳에 열정을 낭비하지 말자.

방파제 코멘트
가끔 코멘트가 코드 사이에 방파제 역할을 하는 경우가 있다.
프로그래머는 중요한 코멘트를 특별하게 표시할 필요가 있는데 한 소스파일 안에 여러개의 클래스가 구현되어 있는 경우, 중요 섹션을 구분하기 위해 방파제 코멘트를 사용한다.
/***********************************
* 방파제 코멘트
* 가끔 필요할 때가 있다
***********************************/
좀 전에 함부로 사용하지 말라고 한 것과 비슷한 모양이지만 눈에 띄는 것이 중요하지 ASCII예술을 통해 이쁘게 하지 마라. (ASCII예술이란 특정한 상황에서 띄어쓰기 등으로 화면에 보이는 것을 미술적으로 표현하는 것을 말하는 듯하다.)

플래그
다른 사람의 코멘트를 읽을 때 약속된 플래그를 알아두는 것이 좋다.
// XXX      : 문제를 일으키는 코드나 재작업이 필요하다는 표시
// FIXME   : 고장 난 부분
// TODO    : 누락된 기능(나중에 돌아왔을 때 추가해야 할 기능)
TODO를 사용하기 보다는 exception을 던지는 것이 훨씬 매끄럽다. 하지만 다른 사람이 해놓은 것을 알아볼 필요는 있겠지.
하지만 플레그를 두려워 하지 마라. 코드를 마무리하기 전에 플레그를 검색해보면 된다.

파일헤더 코멘트
앞에서도 이야기 했던 내용이다. 모든 소스 파일에는 헤더 코멘트로 시작해야 한다.

불필요한 코멘트
코드를 수정할 때 코멘트를 달지마라.
어떠한 내용을 무엇때문에 어떻게 고쳤다..라고 코멘트를 다는 것은 불필요하며 지저분하다. 필요한 경우 결함 추적 시스템(fault-tracking system)을 이용해 결함을 찾고, 파일의 예전 리비전을 끄집어내어 조사할 수 있다. 이러한 불필요한 코멘트는 오히려 코드를 어지럽힌다.

코멘트 유지보수
바로 위에서 코드를 수정할 때 코멘트를 달지 말라고 했다. 그렇다면 코드를 수정할 때는 그냥 넘어가면 되는 것인가? 절대 아니다.
코드를 수정할 경우 그와 관련된 코멘트를 모두 확인하고 보수해야 한다.

코멘트를 의심하라
코드를 코멘트로 막아두는 경우가 있다. 일시적인 경우지만 때로는 오래갈 때도 있다. 이런 경우 적당한 설명을 함께 두거나 아예 코드 자체를 지워야 한다.
코멘트가 있더라도 코드의 수정과 함께 유지보수가 되지 않은 코멘트일 수 있고 작성한 사람이 잘못 작성했을 가능성도 있다. 항상 코드를 신뢰하고 코멘트는 의심해야 한다.


-----------정리-------------
* 소량의 코멘트를 작성하라
* 왜(why)에 대해 작성하라
* 코멘트보다 코드의 작성에 집중하라
* 코드와 함께 유지보수하라
& 코드의 내용을 중복하지 마라
& 자신만 알아보는 코멘트를 작성하지 마라