소스리뷰(XL) 예외처리가 부족하다

[목차(도우미)]

오랜만에 소스코드를 리뷰했더니 입이 근질근질 하던 것이 조금 풀리는 것 같다. 오늘부터는 제목에 길게 소스코드리뷰(번호)를 쓰던 것을 약간 줄여서 소스리뷰(번호)로 쓰기로 한다.

몇가지 테스트를 통해서 강제종료하는 현상을 검출하였다. 그리고 이에 대한 대처 소스 코드 부분을 리뷰하게 되었는데 강제종료한 부분의 직접적인 원인은 해결되었지만 동일한 고려 부족에 의한 제조적 결함은 해결되었다 하더라도 잠재적인 오류의 가능성에 따르는 설계적 결함은 제거되지 않았다. 직접적인 원인이 수정되었을 때 우리는 단지 해결되었다고 만족해 버리는 경우가 종종 있다. 개발자의 흔한 변명인 개발 공수가 부족하고 바빠서 거기 까지는 신경을 쓰지 못했다는 것을 이번에도 듣게 되었다. 여기서 끈질긴 전문가급 개발자와 당장할 일에 바쁜 개발자를 나눌 수 있다고 말해도 좋을 것이다.

적어도 전문가급 개발자를 지향하고 있다면 한번 쯤 멈추어 서서 직접적인 원인이 무엇인가를 끝까지 파고들어서 생각할 수 있는 모든 상황을 망라해서 오류가 없는 무결성 프로그램으 로 다듬으려는 노력을 필요로 한다. 이유야 어찌 되었든 프로그램이 죽는 경우를 발견한 것이니 만큼 철저하게 대처하는 습관이 중요하다. 직접적인 원인을 철저히 규명해서 예외 현상을 모두 조사하여 잡아내는(catch) 하는 과정을 강화해야 한다.

소프트웨어 개발의 관련 서적에 자주 등장하는 사례로서 미국 우주선이 폭발된 원인으로 프로그램 버그가 있었던 것인데 그 버그, 오류는 0값으로 나누는 처리를 빠트렸다는 것으로 시스템이 중단 된 것이었다. 코드 한줄이 부족해서 우주선과 세월이 날아가버린 것이다.

리뷰시에도 대충 듣고 넘어가는 등의 예외를 두어서는 안된다. 모든 예외를 처리해 주어야 한다.

키워드: 소스코드, 리뷰, 소스코드리뷰, IT, 프로그램, 프로그래밍, 예외처리, try catch, try except, try finally


by 금메달.아빠 on 2012.07.11 05:30 주요 단어: , , , , , , , , ,