8. 오류 무시하지 않기

오류가 났다고? 무슨 오류? 별문제가 아닐 수도 있다. 솔직히 말하면 그냥 무시할 수도 있다.

하지만 이러한 태도는 견고한코드를 만들기 위한 좋은 전략이라고 할 수 없다. 혹은 단순히 게으름에서 비롯된 결과일 수 있다.

코드 안에 오류가 있을 것으로 여겨지지 않아도, 만약을 대비해 항상 유심히 확인하고 검토해야 한다.

1. 메커니즘

우리는 여러 바법으로 코드의 오류를 확인한다.

코드 응답   

함수는 값을 반환한다. 그중 어떤 것들은 작동하지 않음 을 뜻한다. 오류에 대한 반환 코드는 무시되기 십상이다. 코드에 문제가 있음을 알리는 어떤 것도 발견되지 않을 것이다. 반환 코드는 가장 보편적인 오류 검출 방법이다. 함수들은 값을 반환하고, 운영 체제 프로세스도 값을 반환하며, 어떤 시스템에서는 스레드 역시 값을 반환한다.

부수적 작용

분리된 전역 변수로서 오류 신호로 사용되는 errono는 부작용의 전형적인 사례로, C 언어의 흥미로운 이상 현상으로 꼽힌다. 이것은 지나치기 쉽고, 사용하기는 어려워 심각한 문제를 발생시킬 수 있다.

예외

예외는 언어 자체에서 기원하는, 보다 구조적으로 오류를 전달하고 다루는 바업이다. 그러니 결코 무시하고 넘어갈 수 없다.

예외는 완벽하지 않다. 예외를 비난하는 사람들은 그것이 오류 경로를 숨긴다고 불평한다. 예외로 인해 비정상적 경로로 콜스택을 벗어나 부작용을 일으킬 수 있다는 이유에서다 ( 부작용의 사례로 리소스 누수나 함수의 바정상적 작동 등이 있다 ) 그러나 예외를 처리한 함수에서는 오류 처리 자체를 하지 앟ㄴ으므로 이러한 문제가 발생하고 있다는 사실조차 인식할 수 없다.

예외를 효과적으로 사용하기 위해서는 많은 규칙을 따라야 한다.

2 광기

오류를 적절히 처리하지 않으면 다음과 같은 일이 발생할 수 있다.

불안정한 코드

이러한 유형의 코드는 찾아내기 어려운 충돌로 가득 차 있다.

불안전한 코드

크래커들은 소프트웨어 시스템을 파괴하기 위해 종종 오류 처리 과정의 취약점을 이용한다.

나쁜구조

만약 반복적으로 다루어야 하는 오류로 인해 코드가 지루해 진다면, 그것은 좋지 않은 인터페이스 때문일 수 있다. 인터페이스를 개선하면 오류가 성가셔지지 않을 것이다.

코드에서 모든 잠재적인 오류를 확인해야 하는 것처럼, 사용자 인터페이스에서도 모든 잠재적인 잘못된 상황을 노출시켜야 한다. 그것들을 숨기지 말자. 정상적으로 작동하는 것처럼 보이게 만들지 말자.

프로그래머는 프로그램의 오류에 대해 알아야 한다. 마찬가지로 사용자는 사용 중에 발생하는 오류에 대해 알아야 한다.

어떤 부지런한 운영자가 어느 날 오류를 알아채고 조치하길 기대하는 것은 좋지 않다. 

3. 감형 사유

왜 오류를 확인하지 않을까? 많은 이유가 있을 것이다.

• 오류 처리로 인해 코드의 흐름이 방해되고 코드 읽기가 어려워지며, 정상적인 실행 흐름을 알아보기 힘들다.
• 마감 시간은 다가오는데 추가 업무의 부담이 있다.
• 이 함수에서는 절대 오류가 발생하지 않는다는 사실을 알고 있다.
• 이것은 정말 간단한 프로그램이어서 상용 수준으로 작성할 필요가 없었다.
• 언어가 나와 맞지 않는다

요점은 간단하다. 

오류를 무시하지 말자