예외 처리

쓸 수 없는 검증

• 프로그램이 파일을 엽니다. 파일을 열기 전에 해당 파일이 존재하는지, 읽을 수 있는지, 디스크가 연결되어 있는지를 검증할 수 있습니다. 모든 검증이 통과한다고 가정해 봅시다.
• 마지막 검증과 열기 사이에서 사용자가 USB 스틱을 제거합니다. 질문했을 때는 파일이 존재했으나 열 때는 존재하지 않으며, 사전 검증으로는 이 간극을 메울 수 없습니다.
• 일부 오류는 테스트와 실행 사이 세상이 변하기 때문에 단순히 예방할 수 없습니다. 프로그램이 할 수 있는 일은 오류가 발생할 때 대응하는 것입니다.
• 이 교훈은 예외이며, 하나를 처리하는 TRY 구조이고, 프로그램 내에서 예외를 잡아야 하는 위치입니다.

예외란 무엇이며 왜 처리해야 하는가

• 예외는 실행 중 발생하는 오류: 0으로 나누기, 파일 찾지 못함, 유효하지 않은 입력, 네트워크断开 등입니다.
• 예외 처리는 프로그램이 오류를 감지하고 crashing하여 사용자의 작업을 잃는 대신 통제된 방식으로 대응할 수 있게 합니다.
• 실제 프로그램은 후크가 보여주는 것처럼 사전 방지할 수 없는 오류에 직면합니다. 그리고 예외가 없다면 모든 연산마다 자체적인 IF 검증이 필요하여 실제 알고리즘이 오류 테스트 속에 묻히게 됩니다.
• 세 번째 장점은exam에서 가장 자주 묻는 것입니다: 정상 흐름과 오류 처리를 분리하여 주요 경로가 깔끔하게 읽히게 합니다.

TRY 구조

TRY
    OPENFILE "data.txt" FOR READ
    READFILE "data.txt", line
    CLOSEFILE "data.txt"
EXCEPT FileNotFound
    OUTPUT "Sorry, the file does not exist."
EXCEPT ReadError
    OUTPUT "Sorry, there was an error reading the file."
FINALLY
    OUTPUT "Finished attempting to read."
ENDTRY

• TRY 블록은 실행 중 오류가 발생할 수 있는 코드를 포함합니다. 에러 없이 실행되면 EXCEPT 블록은 완전히 건너뜁니다.
• 예외가 발생하면 실행이 즉시 첫 번째 매칭 EXCEPT 블록으로 점프합니다. TRY 블록의 나머지 부분은 실행되지 않습니다.
• FINALLY 블록은 예외가 발생했는지 여부와 상관없이 실행되므로, 파일 닫기와 같은 정리 작업에 적합한 위치입니다.

모든 것이 잘 될 때의 한 경로, 그렇지 않을 때의 다른 경로, 그리고 항상 실행되는 하나의 경로

worked example: 흐름 추적

예외 발생(Raising an exception)

• 스스로 해결할 수 없는 문제를 감지한 서브루틴은 예외를 발생(raise) 시켜 호출자에게 책임을 넘길 수 있습니다:

IF b = 0 THEN RAISE DivideByZero

• 서브루틴이 문제가 있음을 알고 있지만 어떻게 해야 할지는 모르는 경우, 이 설계가 적절합니다. 나눗셈 루틴은 제수가 0임을 알지만, 호출자가 다시 요청할지 기본값을 사용할지 계산 중단을 할지는 callers에게 맡겨야 합니다.

처리의 위치

• 반응이 간단하고 국소적일 경우(메시지 출력, 기본값 사용, 사용자 재시도 요청 등) 예외를 발생 부근에서 처리하십시오.
• 결정이 프로그램의 더 큰 부분에 속할 경우(전체 거래 중단, 변경 사항 되돌림, 작동 실패 알림 등) 상위 수준에서 처리하십시오.
• 경험칙: 먼저 발견하는 수준이 아니라, 무엇을 할지 결정할 수 있는 정보가 충분한 수준에서 잡으십시오.

worked example: 해서는 안 되는 것

놓칠 수 있는 점

이해했습니다