에러와 예외
어떤 원인에 의해 오동작 하거나 비정상적으로 종료되는 경우
심각도에 따른 분류
- Error
ㄴ 메모리 부족, stack overflow와 같이 발생하면 복구할 수 없는 상황
ㄴ 프로그램의 비정상적 종료를 막을 수 없음 → 디버깅 필요
- Exception
ㄴ 읽으려는 파일이 없거나 네트워크 연결의 단절 등 수습이 가능한 상황
ㄴ 프로그램 코드에 의해 수습될 수 있는 상황
예외 처리
- 예외 발생 시 프로그램의 비정상 종료를 막고 정상적인 실행 상태를 유지하는 것
예외 클래스의 계층
checked exception
- 예외에 대한 대처 코드가 없으면 컴파일이 진행되지 않음
- 필수적으로 예외처리 수행
unchecked exception
- 예외에 대한 대처 코드가 없더라도 컴파일은 진행됨
- 개발자가 예외 발생 가능한 상황을 고려해야 함
try ~ catch 구문
try ~ catch 문에서의 흐름
- try 블록에서 예외가 발생하면
ㄴ JVM이 해당 Exception 클래스의 객체를 생성 후 던짐(throw)
(throw new XXException() )
ㄴ 던져진 exception을 처리할 수 있는 catch 블록에서 받은 후 처리
ㄴ 적당한 catch 블록을 만나지 못하면 예외처리는 실패
- try블록에서 예외가 발생하지 않은 경우
ㄴ catch 문을 거치지 않고 try-catch 블록의 다음 흐름 문장을 실행
다중 exception handling
다중 exception handling?
- try 블록에서 여러 종류의 예외가 발생할 경우
ㄴ 하나의 try 블록에 여러 개의 catch 블록 추가 가능
다중 catch 문장 작성 시 순서 유의사항
- JVM이 던진 예외는 catch 문장을 찾을 때 다형성이 적용됨
- 상위 타입의 예외가 먼저 선언되는 경우 뒤에 등장하는 catch 블록은 동작할 기회가 X
- 상속 관계가 없는 경우는 무관,
ㄴ 상속 관계에서는 작은 범위(자식)에서 큰 범위(조상) 순서로 정의
try ~ catch ~ finally
finally
- 예외 발생 여부와 상관 없이 언제나 실행
- 중간에 return을 만나는 경우도 finally 블록을 먼저 수행 후 리턴 실행
- 자원정리의 목적으로 자주 사용됨 (자원 반납)
try- with- resuorces
try ~ catch ~ finally 구문을 통한 자원 정리
- finally 블록을 사용하면 코드가 지저분하게됨...
JDK 1.7 이상에서의 리소스의 자동 close 처리
- try 선언문에 선언된 객체들에 대해 자동으로 close를 호출해준다. (finally 역할)
ㄴ 단, 해당 객체들이 AutoCloseable interface를 구현해야 한다.
(각종 I/O 스트림, socket, connection,,,)
- 해당 객체는 try블록에서 다시 할당될 수 없다.
throws 키워드
throws 키워드를 통한 처리 위임
- method에서 처리해야 할 하나 이상의 예외를 호출한 곳으로 전달(처리 위임)
ㄴ 예외가 없어지는 것이 아니라 단순히 전달됨
ㄴ 예외를 전달받은 메서드는 다시 예외 처리의 책임 발생
(본인이 처리 or 또다시 throw)
- 처리하려는 예외의 조상 타입으로 throws 처리 가능
checked exception & runtime exception의 throw
- checked exception
ㄴ 무조건 try~catch 또는 throws 필요!
- runtime exception
ㄴ throw하지 않아도 전달되지만, 결국 try~catch로 처리해야함
로그 분석과 예외의 추적
Throwable의 printStackTrace는 메서드 호출 스택 정보의 조회가 가능
- 최초 호출 메서드에서부터 예외 발생 메서드까지의 스택 정보 출력
- 꼭 확인해야할 정보
ㄴ 어떤 예외인지? (예외 종류)
ㄴ 예외 객체의 메시지는 무엇인가? (예외 원인)
ㄴ 어디서 발생했는가? (디버깅 출발점)
- 직접 작성한 코드를 디버깅 대상으로, 참조 라이브러리는 과감히 Pass
throws의 목적과 API 활용
API가 제공하는 많은 메서드들은 사전에 예외가 발생할 수 있음을 선언부에 명시하고 프로그래머가 그 예외에 대처하도록 강요한다.
만약 throws 하지 않고 내부에서 처리한다면 개발자는 예외 발생을 인지하지 못한다.
사용자 정의 예외
API에 정의된 exception 이외에 필요에 따라 사용자 정의 예외 클래스 작성
대부분 Exception 또는 Runtime Exception 클래스를 상속받아 작성
- checked exception 활용 : 명시적 예외처리 or throws 필요
ㄴ 코드는 복잡해지지만 처리 누락 등 오류 발생 가능성은 줄어듬
- runtime exception 활용 : 묵시적 예외처리 가능
ㄴ 코드가 간결해지지만 예외 처리 누락 가능성 발생
사용자 정의 예외처리의 장점
- 객체의 활용 : 필요한 추가정보, 기능 활용 가능
- 코드의 재사용 : 동일한 상황에서 예외 객체 재사용 가능
- throws 메커니즘의 이용 - 중간 단계에서 return 불필요
