실용주의 프로그래머 : 예외 처리

우리는 예외가 프로그램의 정상 흐름의 일부로 사용되는 일이 거의 없어야 한다고 믿는다. 예외는 의외의 상황을 위해 남겨두어야 한다. 잡히지 않은 예외는 프로그램을 종료시킬 것이라고 가정하고, '모든 예외 처리기(exception handler)를 제거해도 이 코드가 여전히 실행될까.'라고 자문해 보자. 만약 그 답이 '아니오.'라면 아마도 예외가 비예외적인 상황에서 사용되고 있는 것이다.

"실용주의 프로그래머" page 208

처음 C 언어를 배워서 프로그래밍을 할 때는 사용자가 관리자의 의도와 상관없는 행동으로 프로그램이 에러가 날 수 있는 부분을 if나 다른 명령을 통해서 처리하였습니다. 그 뿐만 아니라 시스템이나 다른 외부의 영향에 의해서 프로그램이 오동작 할 부분도 처리를 했었죠.

이런 기법들이 자바나 파이썬 등과 같은 예외 처리(Exception handler)를 지원하는 언어들을 만나면서 예외를 이용한 에러처리 방법으로 바뀌게 되었습니다. 이 방법이 기존의 if를 이용하는 방법에 비해서 여러면에서 쉬웠기 때문에 실제 코드에서 이용하게 되는 일이 많아졌는데요, 어느 때 부턴가 예외가 그렇게 좋은 것은 아니다 라는 말을 듣게 되었습니다. 그래서 왜 좋지 않은지 찾아봤으나 잘 이해가 되지 않았었는데, 오늘 위의 인용된 글을 읽으면서 머리를 관통하는 생각이 있었습니다.

결국 예외라는 것은 프로그램의 정상적인 흐름을 방해하는 부정적인 요소들이며 그 부정적인 요소들을 처리하기 위한 방법으로 예외 처리를 쓰는 것이라는 걸 알았습니다. 결국 무심하게 사용했던 당연하게 예외가 발생할 부분을 만들고 그걸 처리하는 부분에 프로그램의 루틴을 넣었던 것이 문제였다는 것을 알게 되었습니다. 예외를 처리하기 위해 예외 처리를 사용하는 행위 자체에서 새로운 문제가 발생할 수도 있다는 것을 알고 사용하는 것은 무심하게 사용하는 것과 차이가 있을 거라 생각합니다.

"실용주의 프로그래머"의 저자는 우리가 경계해야 하는 이유에 대해서 명확하게 설명하고 있습니다.

왜 우리는 이런 식으로 예외에 접근할 것을 제안하는가? 예외가 있다는 것은 즉 컨트롤의 이동이 즉각적이고 로컬하지 않다는 것을 말한다. 일종의 연쇄 goto 같은 것이다. 예외를 정상적인 처리 과정의 일부로 사용하는 프로그램은 고전적인 스파케티 코드의 가독성 문제와 관리성 문제를 전부 떠안게 된다. 이런 프로그램은 캡슐화 역시 깨트린다. 예외 처리를 통해 루틴과 그 호출자들 사이의 결합도가 높아져 버린다.

"실용주의 프로그래머", page 210