1. exception handling
- 프로그램 개발중에 발생하는 예외 event를 처리하는 것을 말한다.
- c언어처럼 예외처리 메커니즘이 제공되지 않는 환경에서도 물론 if case로 처리할 수 있긴하다.
- 위의 코드는 파일을 읽고 처리후 파일을 닫는 코드이다.
- 파일 열기가 실패했을때, 파일의 size를 알아내기가 실패했을때, 등의 여러 예외 상황에 대한 대처가 부족하다.
- 따라서 예외 상황을 다 분기하면 코드가 상당히 읽기 어려워진다.
- 즉 정상적인 flow과 비정상적인 예외 상황을 처리하는 flow간의 분리가 잘 안되어있다.
- 그래서 exception handling이 꼭 필요하다.
- catch문을 통해 flow의 분리가 명확해졌다. (+가독성 향상)
- 이번에는 함수가 call stack을 이루는 예시를 살펴보자.
- 모든 상황을 직접 매뉴얼하게 처리한 모습이다.
- exeption handling으로 깔끔하게 처리할 수 있다.
- 하위 stack의 함수의 에러를 propagation하기 용이하다
- 게다가 exeption이 객체로 관리되기 때문에 error type을 세분화하거나 그룹화하기 용이하다.
- filenotfoundexception은 ioexception의 일종이다. ioexception중에서 filenotfound만 골라서 더 구체적으로 처리할 수 있다.
- 만약 매뉴얼하게 에러 코드를 1,2,3으로 해버리면 그룹화와 세분화가 어렵다.
2. 예외처리에서의 에티켓
- 한가지 명심해야 할것은 exception을 받았다면 반드시 처리해야 한다는 것이다. (catch하고 ignore하지 말아라)
- 그 뒤에도 다양한 handler들이 대기하고 있을것이기 때문에 내가 처리하기 어려운데 잡아버리면 뒤에서 기다리는 핸들러가 에러를 인지하지 못하게 된다.
- 만약 잡은 에러를 부분적으로만 처리할 수 있다면 다시 다음 핸들러를 위해 에러를 던져줘야 한다.
- 게다가 위 예시에서는 최상위 클래스인 Exception으로 에러를 잡고 아무것도 안한다. 그럼 그 하위 exception들이 전부 여기에 걸려서 뒤에 핸들러들이 error를 볼 수 없게 된다.
3. Exception Types
- error : 예상하지 못하는 오류에 대해서는 발생되는 예외적인 상황이다. application에서 예측할수도 없고 캐치해도 뭔가 처리할 수 있는게 없다. ex) stack overflow.
- runtime exception : 응용프로그램 실행중 내부에서 발생하는 예외,버그에 대해 사용한다. ex) division by zero, null point exception. 마찬가지로 catch 해서 딱히 뭘 처리할수있는게 없다.
- checked exception : error, runtime exception을 제외한 예외사항을 말한다. 잘 만들어진 프로그램이라면 checked exception을 다 처리할 수 있어야 한다. catch로 잡거나 새로운 error class로 specify할 수 있다.
4. Fundamentals
- try : 모니터가 필요한 program statement가 들어가는 block
- catch : try block에서 발생한 error를 catch하는 block
- throw : manual하게 error를 던질 수 있다.
- try안에서 throw를 수동으로 던지는 예시이다.
- throwdemo 함수에서 끝나기 전에 또 throw를 던져줘서 바깥의 main이 그 exception을 또 받을 수 있게 되었다.
- 이렇게 하면 예외의 일부를 처리하고 나머지 처리를 다음 메서드에게 propogate할 수 있다.
- 첫번째는 0으로 나누는 예외를 처리하고
- 두번째는 out of bound를 잡는 catch문이다.
- 이렇게 catch문이 많을 때는 순서대로 하나씩 체크한다. 만나는 첫 케이스에서 소멸되어 try,catch를 빠져나온다.
- 예외는 첫 케이스 catch에서 소멸되기 때문에 superclass exception이 상위에 있어버리면 subclass는 절대 예외를 잡지 못하므로 조심하자. (specific한 예외가 항상 상위에 있도록)
- java의 경우 이렇게 superclass exception이 상위에 있으면 아예 컴파일이 안된다.
- 두 예제의 결과를 잘 비교해보자
5. Uncaught Exception
- user program에서 아무도 catch하지 못한 exception은 (java의 경우) java runtime이 마지막으로 잡고 default handler가 예외를 처리한다.
- default handler는 stack trace를 출력한다.
6. Throws
- error, runtimeException을 제외한 checked exception에 한해서 throws를 사용할 수 있다.
- 어떤 메서드가 처리하지 못하는, 호출자에게 처리를 위임해야 하는경우 throws를 통해 명시한다.
- 이렇게 명시적으로 exception을 던지면서 throws로 명시하지 않으면 컴파일조차 되지 않는다.
- 올바르게 수정한 모습이다.
7. Finally
- finally : try문을 나가기 전에 반드시 한 번 수행되어야 하는 block.
- catch에서 잡히고 안잡히고와 무관하게 try/catch를 벗어나기 전에 반드시 수행된다.
- return, break가 finally 보다 앞에 있더라도 반드시 실행된다.
- 단, system.exit()같은 셧다운은 결과를 알수 없다.
- 0번 경우 : finally -> last statement -> 종료
- 1번 경우 : finally -> return종료
- 2번 경우 : 셧다운,종료
- 3a번 경우 : finally -> last statement -> main catch block
- 3a,3b 경우 : try에서 throw하고 catch에서도 throw하기 때문에 절대 last statement는 실행될수가 없다. 컴파일러가 이를 확인하고 에러를 표출한다.
'ComputerScience > Software Engineering' 카테고리의 다른 글
소프트웨어공학 - 21. Code coverages for white box testing (0) | 2022.06.03 |
---|---|
소프트웨어공학 - 20. Verification and Validation (V&V) (0) | 2022.06.01 |
소프트웨어공학 - 19. Test-Driven Development (0) | 2022.05.29 |
소프트웨어공학 - 18. SOLID (0) | 2022.05.19 |
소프트웨어공학 - 17. GRASP (0) | 2022.05.12 |