예외(Exception)란 프로그램의 정상적인 실행을 방해하는 조건이나 상태를 의미하는데 프로그램을 잘못 작성해서 오동작하거나 다운되게 만드는 에러(Error)와는 다르다. 원칙적으로 에러는 개발중에 모두 수정해야 하는데 모르고 들어가는 것은 할 수 없지만 일단 에러가 있다는 것을 알았으면 그냥 남겨 두지 않을 것이다. 최종 릴리즈할 때까지 미처 발견하지 못하면 이것을 버그라고 부르며 그 중에서도 아주 악질적인 에러를 뻐~그라고 부른다. 예외란 버그와는 달리 제대로 만들었지만 원하는대로 동작하지 못하게 방해하는 외부의 불가항력적인 상황을 말한다.
프로그램을 아무리 치밀하게 논리적으로 잘 작성하더라도 예외는 항상 발생할 수 있는데 왜냐하면 작성 시점에서 실행 시의 모든 상황을 정확하게 예측할 수 없기 때문이다. 예외가 발생하는 가장 큰 이유는 프로그램을 사용하는 사람이라는 존재가 워낙 불확실하기 때문이다. 항상 정해진 절차대로 프로그램을 동작시키고 정확한 값만 입력한다면 문제가 없겠지만 실수 투성이인 사람은 그렇지 못하다.
프로그램이 실행되는 환경 또한 불확실하기는 마찬가지이다. 하드 디스크가 언제 가득찰 지 예측할 수 없으며 프린터의 종이가 언제 떨어질 지도 알 수 없다. 또한 컴퓨터 외부의 환경인 네트워크도 불안정해서 언제든지 끊어질 수 있고 알 수 없는 이유로 데이터가 중간에서 사라지기도 한다. 잘 짜여진 프로그램은 이런 여러 가지 예외 상황에도 잘 대처해야 하는데 잘못된 입력이 왜 잘못되었는지 사용자에게 알리고 다시 입력하도록 해야 하며 실패한 동작은 재시도해야 한다. 어떤 경우라도 최소한 프로그램이 다운되지는 않도록 해야 한다. 예외를 잘 처리하지 못하면 이것도 일종의 버그가 된다.
프로그램은 사용자와 상호 작용하거나 외부의 환경과 통신할 때 항상 방어적인 코드로 발생 가능한 모든 예외를 적절하게 처리해야 한다. 다음 코드는 사용자로부터 두 개의 정수값을 입력받아 두 값을 나눈 결과를 출력한다.
int a,b;
printf("나누어질 수를 입력하시오 : ");
scanf("%d",&a);
printf("나누는 수를 입력하시오 : ");
scanf("%d",&b);
printf("나누기 결과는 %d입니다.\n",a/b);
사용자가 정상적인 값만 입력한다면 이 프로그램은 아무 문제가 없다. printf가 출력하다 실패할리 없고 scanf가 입력을 못 받을리도 없다. 그렇다고 그 정확한 CPU가 그까짓 나눗셈을 틀릴리도 만무하다. a에 6, b에 3을 입력하면 그 결과로 2가 정확하게 출력될 것이다. 그러나 나누어지는 수로 0을 입력하면 이 프로그램은 나눗셈 연산을 하던 중에 예외를 일으키고 다운되어 버린다. 수학적으로 불가능한 연산이므로 b에 절대로 0이 입력되어서는 안된다. 또 a와 b가 좌표값이나 배열의 첨자라고 가정할 때 두 값 모두 음수여서는 안된다는 규칙이 적용된다. 이런 잘못된 입력에 대해 프로그램은 예외를 처리해야 하는데 전통적인 방법은 값을 사용하기 전에 if문으로 입력된 값을 점검하는 것이다.
|
예 제 : TraditionalError |
#include <Turboc.h>
void main()
{
int a,b;
printf("나누어질 수를 입력하시오 : ");
scanf("%d",&a);
if (a < 0) {
printf("%d는 음수이므로 나누기 거부\n",a);
} else {
printf("나누는 수를 입력하시오 : ");
scanf("%d",&b);
if (b == 0) {
puts("0으로는 나눌 수 없습니다.");
} else if (b < 0) {
printf("%d는 음수이므로 나누기 거부\n",b);
} else {
printf("나누기 결과는 %d입니다.\n",a/b);
}
}
}
a를 입력받은 후 if문으로 이 값이 음수인지 점검한다. 만약 음수라면 에러 메시지를 출력하여 잘못된 값임을 알린다. 그렇지 않다면 b를 입력받고 이 값이 0인지, 음수인지를 점검한다. 이 모든 조건이 만족할 때만 a/b 연산 결과를 출력하고 그렇지 않다면 연산을 거부한다. 틀린 값을 입력했을 때 다시 입력받으려면 전체 코드를 while 등의 무한 루프로 감싸고 성공했을 때만 break로 빠져 나오도록 하면 된다.
if문으로 조건을 점검하여 예외를 일으킬만한 상황을 피해가는 이런 전통적인 방법은 지금까지 많이 사용해왔고 또 지극히 상식적인 방법이다. 하지만 점검할 예외가 많아지면 여러 가지로 코드의 품질이 떨어진다. 다음 예는 메모리를 할당하고 값을 입력받아 계산하고 그 결과를 파일로 출력하는 코드인데 발생 가능한 예외가 무척 많다.
size=필요한 메모리 양 조사
if (size < 100M || size > 0) {
ptr=malloc(size);
if (ptr) {
if (InputData(ptr) == TRUE) {
if (CalcData(ptr) == TRUE) {
File=파일 열기();
if (File) {
if (파일 쓰기()) {
에러 출력("파일 쓰기 실패");
}
파일 닫기();
} else {
에러 출력("파일을 열 수 없음");
}
} else {
에러 출력("계산중 에러 발생");
} else {
에러 출력("입력중 에러 발생");
}
free(ptr);
} else {
에러 출력("메모리 할당 실패");
}
} else {
에러 출력("요구하는 메모리 크기가 너무 크거나 황당하게 작음");
}
너무 많은 메모리를 요구하거나 메모리 할당에 실패할 수도 있고 입력 중에 에러가 발생할 수도 있으며 계산 중에 오동작할 수도 있다. 또한 파일을 열거나 쓸 때도 여전히 실패할 가능성이 있다. 이 모든 예외 상황에 대해 일일이 if문으로 조건을 점검해야 하며 그러다 보니 실제로 작업을 하는 코드보다 예외를 판단 및 처리하는 코드가 훨씬 더 많다. 예를 위해 일부러 꼬아 놓은 코드가 아니며 실제 상황은 이보다 훨씬 더 복잡해질 수도 있는데 그만큼 예외는 자주 발생한다.
이런 처리를 하려면 모든 함수는 성공 여부를 리턴해야 하며 함수를 호출하는 곳에서는 리턴값을 일일이 점검해야 하므로 무척 번거롭다. 실제 작업을 하는 코드와 예외를 처리하는 코드가 중간 중간에 섞여 있어 관리하기도 어렵고 코드의 핵심을 파악하기도 쉽지 않다. 에러를 점검하는 if문과 에러 메시지 출력문이 너무 떨어져서 대응되는 코드를 한눈에 알아보기도 어렵다. 게다가 잦은 if문으로 인해 들여쓰기가 지나치게 깊어져 코드의 모양이 꼴사납다. 이순신 장군의 학익진과 유사한 모양인데 싸울 때는 좋을지 몰라도 코드를 관리할 때는 별로 좋지 않다.
이런 코드를 분석할 때는 잘 발생하지 않는 예외 코드는 일단 무시하고 읽어야 하는데 무질서하게 섞여 있다 보니 어디가 예외 처리 코드인지 어디가 진짜 코드인지 잘 분간되지도 않는다. 안정적인 프로그램을 만들기 위해서는 발생 가능한 모든 예외를 처리할 필요가 분명히 있다. 그러나 전통적인 방법은 여러 가지로 좋지 않은 효과가 있어 질적으로 다른 방법이 필요해졌다.