함수를 만들때 에러처리를 어떻게 하는게 좋은지 조언부탁드립니다.

제가 보기엔 최초에 설계한 구조가 더 괜찮아 보입니다.

당장은 func_b()에서 바로 exit하는 것이 편해보이겠지만

유지의 측면에서 보자면, func_b()에서 exit로 인해

프로그램 종료가 일어난다는 사실을 기억해야 하는 단점이있습니다.

복잡함을 줄여보고 싶다면

차라리 main에서 exit하면서 자원해제에 신경을 안쓰는 것이

속편하지 않을까요. 다음과 같이요.

if(func_a() < 0) exit(1);

======================

어떤 기능을 수행하는 함수가 error 처리까지 다 하게 작성하는 것은 항상 좋다고 할 수 없습니다. 보통은 기능을 수행하는 함수에서 error가 났다는 정도만 알리게 하고, 이 함수를 호출한 상위 함수에서 error를 처리하게 하는 것이 좋습니다. (왜냐하면, error를 처리할 user interface가 상황에 따라 달라지게 때문입니다.)

무조건 error를 만나면 나몰라라하고 exit(1)를 하는 것도 항상 좋다고 할 수 없습니다. 한 번 실행되고 바로 끝나는 류의 utility라면 상관없겠지만, 장기간 동작해야 하는 daemon type이라든가, embedded system에 들어가서 안정적으로 동작해야 될 프로그램일 경우, exit(1)를 부를 수 없는 상황이 많습니다.

프로그램 구조가 복잡해져서, function call depth가 깊고, 빨리 상단으로 복귀해야 할 경우, setjmp()/longjmp()가 유용합니다. (사실 toy software가 아닐 경우, sigsetjmp()/siglongjmp()가 더 자주 쓰입니다.)

C++에 있는 try/catch도 위 함수들을 활용해서, macro로 흉내내는 것도 가능합니다.

아주 드문 경우이긴 하지만, setjmp()/longjmp()를 쓰기 곤란한 경우도 있습니다. 이 경우, 특별한 해결책이 있는 것은 아니지만, 모든 함수에 공통적인 인자를 제공하고, 그 인자 값에 따라서 자동으로 함수 호출을 끝내는 방법도 있습니다.

예를 들면, 특정 함수들은 struct foo *를 첫번째 인자로 받게 설계한 후:

struct foo {
  int errno;
  ...
}

모든 함수 첫 부분에서 foo->errno가 0이 아닐 경우 return하게 합니다.

void bar(struct foo *f, ...)
{
  if (f->errno)
    return;
  /* ... */
}

물론 이런 방법이 꼭 좋다고 할수는 없지만, 봐 줄 수 있는? 상황이 있기도 합니다. 이 경우 각 함수의 return type에 따라서 if (f->errno) .... 를 macro로 등록시켜두고 쓰는 것이 좋습니다. 예를 들면:

#define FOO_ERR_RET(foo, err, ret)     do {                                \
                                          (foo)->error = err;               \
                                          return (ret);                     \
                                        } while (0)

#define FOO_ERR_GOTO(foo, err, label)  do {                                \
                                          (foo)->error = err;               \
                                          goto label;                       \
                                        } while (0)

#define FOO_ERR_STMT(foo, err, stmt)  do {                                \
                                          (foo)->error = err;              \
                                          do {                             \
                                            stmt;                          \
                                          } while (0);                     \
                                        } while (0)

저도 관심있는 주제였는데 토론이 되서 반갑네요. ㅎㅎ

저도 함수내에서 exit를 부르는 것은 반대입니다.
전체적인 함수 구성이 모듈화,계층화 원칙을 지킨다면
함수 내에서 exit를 부르는 것은 전체 처리 플로우를 결정해버리는 것이
되버리니깐 모듈화가 깨지는 것으로 봐도 무방하지 않을까 생각됩니다.

즉 모듈화의 장점을 유지하기가 어렵죠.
따라서, SW가 커지면 커질수록 재사용이나 유연한 확장성 같은
모듈화의 장점을 고스란히 가져가기가 어려울듯 싶습니다.
위엣분들 말씀대로 데먼 같은 경우 더더욱 그럴 수는 없구요.

cinsk님 말씀대로 함수는 성공했는지,실패했는지 여부만 알려주고
처리 플로우에 대한 선택은 콜하는 주체에서 선택하게 하는게
모듈화라는 원칙하에서 맞지 않을까 싶습니다.

저같은 경우 에러 처리는
success,error,info,warn 등의 수평레벨과
normal,verbose,high,extrem의 수직레벨을 나누어서
각 로그들을 두 개의 적절한 조합으로 선택하고
수직레벨은 컨피그에서 선택하여
필요한 로그 이상만 로그하는 방식으로 구현했습니다.
즉 컨피그에서 verbose라고 되어 있으면 normal,verbose만 찍는 방식입니다.

제가 만드는 SW는 고객에게 제공되는 패키지이기 때문에
위 로그 레벨은 고객이 참조하는 로그들이고,
추가로 수평레벨에 개발자용 로그를 추가했습니다.(debug 모드)
이 모드 역시 컨피그에서 on/off로 선택하게 하여
고객이 문제가 생겼다고 리포트할 경우는
debug 모드를 온 시키고 모니터링 하도록 했습니다.
(물론 그럴경우 로그는 과다)

그리고, 고객들이 눈에 띄게 해서 저희쪽으로 리포트해야되는 로그들만
ERR로그로 찍고 나머지는 info나 warn으로 찍었습니다.
그리고 서후니님 말씀처럼 저도 connection fail 같은 경우는 처음에 error로그로 찍었었는데, 고객들 클레임이 자주 들어오더군요.
그런 경우 대부분 error이 아닌데...
따라서, memory short, file full, app logic error 같은 경우만 error로 찍고,
connection fail 같은 경우는 모두 info로 처리했습니다.

그리고 connection 함수를 부르는 놈이 connection fail 에러 상황에 대한
serious 여부 판단을 해서 고객이 인지해야 하는 경우는
그 함수 상위에서 다시 error로그를 다시 잘 설명해서 찍어주는 방식으로 만들었습니다.

그런데, 저도 몇년동안 그렇게 만들어 오기는 했지만,
그런데 함수 자체에 로그가 있는 방식에 대해서
그대로 좋은 것인지 아니면 c standard library처럼
함수 내부는 로그가 없이 errno 같은 형태로 에러 상태만 전달해주는
방식이 맞는지 항상 좀 의문점을 가졌었습니다.

물론 라이브러리의 사용 범위가 한정 패키지에만 쓰이는 것이 아니라
좀 더 넒은 범위의 SW들에서 공유가 되어야 한다면 로그를 쓰지 않고
errno 형태의 에러 전달방식을 쓰는 것이 맞겠지만,
한정 SW라면 로그를 쓰는 것 자체가 문제가 될것인지에 대해서 많이 고민을 하고 있습니다.

모든 라이브러리에 로그를 썼다가 고생한 적이
file io 관련 라이브러리에도 에러 상황에 로그를 썼는데
그 경우에 로그->file io->에러 상황 로그->file io 이런 식으로
루프를 도는 경우가 생겨서 고생한 적이 있습니다.
따라서 로그용 file io(내부적으로 로그 없음)랑
일반 사용용 file io 라이브러리를 구분해서 만들어 놓고 사용하고 있습니다.

서후니님 말씀처럼 저도 일반 로그랑 에러 로그 파일의 구분에 대해서는
고민하고 있었는데, 컬러 로그까지 만드신다니, 좋은 것을 배웠습니다.^^

그런데 저희같은 패키지용 SW에서 로그에 대한 궁극적인 고민의 방식은
결국 고객의 입장에서 편하고, 쉽게 이해하도록 하는 것이 첫번째고,
그 다음은 개발자가 문제를 잘 추적할 수 있도록 만드는게 두번째 기준인 것 같더군요.

두서없이 주저리주저리 써봤습니다.^^;;

메모리같은 리소스는 기본적으로 OS에서 해제해주기는 하지만,
어떤 resource는 해제해주지 않는 경우도 있었습니다.
전 솔라리스에서 프로세스가 죽을때 posix semaphore lock을 해제해주지 않아서 고생한 적이 있었습니다.
솔라리스는 man -s 2 exit에서 프로세스가 죽을때
OS가 어떤 일을 하는지 상세히 설명을 해놓았습니다.
리눅스는 그런 내용은 잘 못찾겠더군요.

어찌됐든 기본적으로 OS는 확실히 믿지 말고 프로그래밍하는
습관을 들이는 것이 좋지 않을까 싶습니다.

흐.... 이건 주제에 어긋나지만...

위에건 원래 세마포어의 작동 원리입니다.
프로세스가 죽어도 unlock 안되는게 정상입니다.
(저도 처음에 놀랬습니다.)
하지만, 별도의 옵션 셋팅으로 프로세스가 죽으면 초기 상태로 가도록 할 수 있습니다.

semop 의 man 페이지를 보면

공유메모리를 생성한 프로세스가 죽어도 공유메모리가 남아 있는 것과 비슷한 느낌이지요.(이 사실을 처음 알았을 때도 역시~ 놀랬습니다. ^^)

아! 그리고 쎄후니 라고 읽어 주세요 ^^;