파이썬 여행 #2: 예외 받기

파이썬에서 예외 처리는 엄청나게 유용한 특징이다. 본인은 C 프로그래밍을 배경으로 자랐는데, 거기에서는 정말로 "올바른" 프로그램을 작성하려면, 코드의 절반을 세속적인 에러 점검에 사용해야 한다.

사실, C++에 예외 처리가 있지만, 표준 C-라이브러리 함수를 호출한다면 다시 세속적인 방식으로 돌아가야 한다.

위의 난잡한 코드를 파이썬으로 동등하게 다시 작성하면 다음과 같다:

마지막 except 절 아래에 "be careful here"라고 써 놓은 부분에 주목하자. "be careful" 부분이 바로 이 글에서 다루고 싶은 부분이다. 다루고자 하는 주제는 다음과 같다:

1. 처리되지 못한 에러를 전역적으로 잡기.
2. 예외 잡기, 자세하게 설명.
3. 여러 예외를 잡기.
4. "맨" 예외를 사용하면 좋을 때와 나쁠 때.
   
   
   

처리되지 못한 에러를 전역적으로 잡기.

(나의 경험에 의하면) 파이썬에는 최고의 디버깅 도구중의 하나로 특별한 갈고리인 sys.excepthook가 있다. 본인은 언제나 이를 자동으로 처리하는 맞춤 모듈을 나의 프로젝트에 포함시킨다. 작업의 대부분은 (표준 라이브러리에서) cgitb라는 한 모듈이 담당한다. "cgitb"라고 불리우는 이유는 그의 원래 의도가 CGI 스크립트에서 일어난 에러 역추적을 보여주기 위한 것이었기 때문이다. 그러나 다른 종류의 프로그램에서도 똑 같이 쉽게 사용할 수 있다. 다음은 나의 맞춤 에러 처리 모듈이다. 잘라 붙여 넣어보자: 이제 언제든지 "작성실수(thinko)" 에러가 일어날 때마다, 자동으로 잡히고 상세한 디버깅 정보가 파일에 저장된다. 다음은 예이다: 이제 실행하면 무슨 일이 일어나는지 보자 ... 덤프 파일을 보면 무슨 일이 일어났는지 상세하게 알 수 있다. 에러가 일어날 때 지역 변수의 값뿐만 아니라 함수 매개변수들을 어떻게 보여주는지 주목하자 (do_thing_1(value=100)). 보통은 테스트 사례를 다시 실행시키고 회돌이를 돌면서 이 값들이 무엇인지 보아야 한다. 이제 충돌이 일어나자 마자 프로그램 상태의 찰칵그림을 얻는다. 물론, 최종 생산품에서 프로그램이 그렇게 갑자기 충돌하기를 원하지는 않을 것이다. 나는 그런 상황에 최종 사용자가 그 에러를 볼 수 있도록 좀 세련된 GUI 버전을 사용한다. 여기에서는 중요한 부분을 보실 수 있도록 그리고 어플리케이션에 맞게 에러 모듈을 재단하실 수 있도록 뼈다귀 버전을 제시하였다.

초보 파이썬 프로그래머로서, 나는 처음에 무엇에나 try ... except 절을 두르고 싶은 생각이 들었다. 잠시 지나자, 오직 깨끗이 청소할 필요가 있거나 에러 다음에 롤백할 필요가 있는 상태 정보가 있는 곳에만 try .. except절을 두는 것이 훨씬 더 좋다는 것을 깨닫았다. ("작성실수(thinko)" 사례와 같은) 다른 에러들은 전역 처리자에 이르도록 그대로 두는 편이 더 좋다. except 절에 너무 욕심을 내면 실제로 정보를 잃어버릴 수 있다.

멋지게 다음 주제로 나가 보자 ...

예외 잡기, 자세하게.

예외를 아래와 보이는 바와 같이 잡으면, 정보의 일부만 얻을 것이다: 다음은 except 절에 좀 더 많은 정보를 제공하고 사용하는 법을 보여주는 작은 예제이다.

보시다시피, try ... except 절을 작성하지 않을지라도, 여러분은 이미txt으로부터 더 많은 정보를 얻을 것이다. 이제 예외를 잡아서 그의 모든 속성에 접근하는 법을 살펴보자.



편리하게도, 그 때문에 다음 주제로 나아가게 된다 ...

여러 예외를 잡기.

단 하나의 except 절로 여러 예외를 잡을 수 있으면 편리한 경우가 많다. 아래의 예에서, 함수에 건네지는 나쁜 유형을 점검하겠다. 그리고 에러가 탐지되면, 유형마다 따로 예외를 일으키겠다.



모든 예외가 공통 속성을 가지는, 이와 같은 예제에서는 단 하나의 바탕 클래스로부터 모든 예외를 파생시키는 것이 합리적이다. 클래스가 공통 클래스 APIError로부터 파생되도록 재작성하면: 이제 예외를 좀 더 간결하게 잡을 수 있다:

모쪼록 이제 왜 except (IOError,info)를 except IOError, info에 대한 대안으로 사용하면 안되는지 그 이유를 이해하셨기를 바란다. 첫 형태를 시도하려고 했다면, info 클래스의 예외를 잡으려고 시도했을 것인데, 그것은 의도한 바가 아니다 (그리고 info가 정의되어 있지 않다면, 파이썬은 또다른 예외를 일으킬 것이다).

"맨" 예외를 사용하면 좋을 때와 나쁠 때.

본인이 처음 예외에 관하여 배울 때, 코드 블록을 다음과 같이 작성하는 것이 좋은 생각 같아 보였다:

블록 안에서 모든 에러를 확실하게 잡을 수 있기 때문에 나에게는 처음에는 튼튼해 보였다. 여기에는 세 가지 문제가 있다:

1. 예외 유형이 지정되어 있지 않다. 그래서 어떤 종류의 에러가 일어났는지 알지 못한다.
2. info 매개변수가 주어지지 않았다. 그래서 주어진 기타 추가 정보를 모두 버리고 있다.
3. 일어나리라 예상한 에러를 잡을 뿐만 아니라, 본질적으로 일어나리라 예상하지 못한 에러도 가려 버린다:
   try:    
       # I could get an IOError here if "filein.txt" doesn't exist, 
       # or is not readable.
       fin = open('t.py','r')
       
       # I could get an IOError here if I do not have write-permissions
       # in the current directory, or the disk is out of space.
       fout = open('fileout.txt','w')
   
       # I don't expect anything bad to happen here ...    
       for line in fin:
           # filter out comment lines
           if re.match('^\s*#$', line):
               continue
       
   except:            
       # The only errors I *expect* are IOErrors, so obviously
       # I can say this ... or can I??
       print "A file error occurred."
   
   
   이제 이 예제를 실행하고 다음과 같은 결과를 얻었다:
   A file error occurred.
   
   
   그래서 디버깅을 시작했다. 오직 IOError만 일어난다고 예상하고서, 일어날 수 있는 일들을 목록으로 만들었다:
   1. t.py는 존재하지 않는다
   2. t.py는 읽을 수 없다
   3. 권한이 부족하기 때문에 또는 디스크가 용량이 모자라기 때문에 fileout.txt를 만들 수 없다.
      
      
   점검하고 또 점검했다. 그리고 코드가 실패할 만한 "이유가 없었다". 그렇지만, 파일 에러가 있었다는 사실이 들어났다. 문제는 내가 except 절에 구체적으로 지적하지 않았다는 것이고, 때문에 (본질적으로) 진짜 실패를 가려버렸다는 것이다.
   
   except 절이 실제 문제를 보여주도록 재작성하면:
   try:    
       # I could get an IOError if "filein.txt"  doesn't exist, 
       # or is not readable.
       fin = open('t.py','r')
       
       # Same here, if I cannot create "fileout.txt"
       fout = open('fileout.txt','w')
       
       for line in fin:
           # filter out comment lines
           if re.match('^\s*#$', line):
               continue
   
   # Only catch what I am PREPARED to handle!
   except IOError:            
       print "A file error occurred."
   
   
   
   출력결과

   Traceback (most recent call last):
     File "t.py", line 11, in ?
       if re.match('^s*$', line):
   NameError: name 're' is not defined
   아! 물론, 사용하기 전에 re를 반입하는 것을 깜빡하고 잊어버렸다.
   
   이것으로 왜 처리하도록 지정한 구체적 에러만 잡고, 다른 것들은 최상위 수준까지 흘러가도록 놓아두어야 하는지 그 이유를 보여주었기를 바란다 (거기에서 에러를 잡을 수 있다. 즉, 앞서 기술한 "global hook"으로 말이다).
   
   

   가끔, 자격없는 "excepts"도 좋다!

   이제, 즉시 내 말에 모순되게 어떤 경우는 자격없는 except 절이 좋으며, 심지어 바람직한 경우도 있음을 언급하겠다. 내가 항상 마주하는 한 가지 예는 GUI 코드이다. 마우스 커서에 "busy" 상태를 설정하고 나서 기나긴 연산을 시작한다. 중간에 충돌이 일어나면, 영원히 커서에 바쁜 상태를 그대로 두고 싶지는 않을 것이다. 그렇게 되면 사용자가 혼란스러울 수 있다. 다음은 그런 상황에 내가 코드하는 전형적인 방식이다 (여기에서는 wxPython을 사용한다):
   #
   # I'm about to perform a long operation, so set the
   # cursor to the "busy" (hourglass) state
   #
   wx.BeginBusyCursor()
   
   try:
       # A long operation begins here ...
       
       ...
       ...
   
       # when I'm finished, exit the busy state
       wx.EndBusyCursor()
       
   except:
       # cancel the busy state - don't leave the user hanging!
       wx.EndBusyCursor()
       
       # re-raise original error to caller
       raise

   마지막 줄이 중요하다: 맨 raise 서술문을 사용하면, 원래 예외를 다시 일으킬 것이다. 그래서 그 에러는 다시 호출자에게 정보의 손실없이 전파된다.

   경고

   다음과 같이 하고 싶지 않을 것이다:

   try:
       ... stuff ...
       
   except Exception, exc:
       raise exc

   
   
   원래 예외로부터 정보를 잃어버리기 때문이다.
   데이터베이스 트랜잭션에 관련된 상황에서 자격없는 except 절도 사용했다:
   # "pseudo-SQL" code, just to give the idea ...
   try:
       # run entire transaction inside of "try"
       sql.run("begin transaction")
       
       sql.run("insert into ...")
       sql.run("insert into ...")
       sql.run("update ...")
       
       sql.run("commit transaction")
       
   except:
       # undo any changes on error
       sql.run("rollback transaction")
       
       # propagate original error
       raise
   
   
   이는 아주 멋지다. 호출자는 에러가 일어났는지 안다. 그러나, 이미 깨끗이 정리되었기 때문에 데이터베이스 상태에 관하여 신경쓸 필요가 없다.
   
   자격없는 절이 유용한 마지막 예는 쓰레드 프로그램에 있는데 여기에서 나는 전역 데이터 집합을 잠근다:
   from threading import Lock
   DATA_LOCK = Lock()
   
   try:
       DATA_LOCK.acquire()
       
       .. perform operations on global data ...
       
       DATA_LOCK.release()
       
   except:
       # unlock on error
       DATA_LOCK.release()
       
       # propagate original error
       raise
   Written in WikklyText.