예측 가능한 상황의 처리법

예측을 했으면 기능

예측 못했으면 버그

고치기 쉬운 경우 (수정 또는 예외 + 수정)

예측한 상황이고 고치기 쉬우면 고쳐야 함

• 안전하게 고칠 수 있어야 한다는 조건

중요한 것은 고치고 계속 프로그램이 진행되어야 함

예외는 던지고 잡아서 처리하는 개념

• “예외 후 수정”을 포프샘은 선호함
  • 던지고 직접 처리하기 때문에 광의의 수정이라고 볼 수 있음
  • 예외를 외부에 던지면 어떻게 될지 모르기 때문에 내 시스템에서 처리(수정)함
    • 예외를 통해 남에게 알리는 대신 예외를 처리 후 오류 코드를 통해 남에게 알림
• “예외 후 수정”이 불가능해 예외를 던질 수 밖에 없는 상황도 있음

“예외 후 수정”과 수정의 차이점

• 수정은 미리 오류 상황을 검사해서 바꾸는 것
• 예외는 오류 상황이 발생하고 사후적으로 대응하는 것

예외 + 수정 or 수정 or 예외후

고치기 어려운 경우 (예외 + 종료)

고치기 어려우니 못 고침

• 고치면 더 프로그램이 망가질 것 같은 상황
• 고치기 불가능한 경우

고치기 어렵고 쉬운 정도는 주관적임

로그는 반드시 남기는 것이 좋음

로그를 남기는 방법에 2가지 있음

• 문제 지점에서 로그 남기고 바로 종료
  • 예외를 던지지 않음
• main() 함수까지 예외를 던지고 올라온 경로(콜스택)에 따라 로그 남기고 종료

최종 사용자에게 오류를 보여주는 것은 상황에 따라 선택

• 만약 최종 사용자에게 보여주고 싶으면 슬라이드처럼
  • GUI가 존재하면 GUI로 보여주기
    • 예외를 main() 함수까지 중간에 잡지 않고 던지고 로그 남기고 GUI로 팝업 보여주고 종료
• GUI가 없으면 예외를 main() 함수까지 던지고 파일로 로그 남기고 종료

예외 or 종료

예외를 main() 함수까지 던지는 경우 아래 슬라이드와 같은 문제가 발생할 수 있음

1번 방법은 JVM까지 예외가 전파된다는 보장이 없음 참고

2번 방법은 메모리 덤프는 예외보다 정보가 많음 참고

3번 방법은 사람들은 주석을 잘 읽지 않음 참고 (프로그래머는 문서화도 잘 하지 않으며 문서도 잘 읽지 않음, 게으르다)