예외.
exception handling
에러와 예외
- 어떤 원인에 의해 오동작 하거나 비정상적으로 종료되는 경우
- 심각도에 따른 분류
- Error
- 메모리 부족 stack overflow와 같이 일단 발생하면 복구할 수 없는 상황
- 프로그램의 비정상적 종료를 막을 수 없음 => 디버깅 필요
- Exception
- 읽으려는 파일이 없거나 네트워크 연결 안 되는 등 수습될 수 있는 비교적 약체놈들
- 프로그램 코드에 수습될 수 있는 상황
- 예외처리, exception handling 란
- 예외 발생 시 프로그램의 비 정상 종료를 막고, 정상 실행 상태를 유지하는 것
예외 클래스의 계층
- Error
- Checked exception
- 예외에 대한 대처코드가 없으면 컴파일이 진행되지 않음
- Unchecked exceptiom
- 예외에 대한 대처 코드가 없더라도 컴파일은 일단 진행시켜..!
- check는 컴파일러가
- 예외가 발생 시 대비책 있어? 확인 하는 것.
try ~ catch
try {
// 예외가 발생할 수 있는 코드
} catch(XXException e){ // 던진 예외를 받음.
// 예외가 발생했을 때 처리할 코드
}
ex)
try {
System.out.println(intArray[2]);
} catch(ArrayIndexOutOfBoundsException e){
System.out.println("예외..");
}
Throwable 의 주요 메서드
- public String getMessage()
- public Throwable getCause()
- public void printStackTrace()
try - catch 문 흐름
- try 블록에서 예외가 발생
- JVM이 해당 Exception 클래스의 객체 생성 후 던짐(throw)
- 던져진 exception을 처리할 수 있는 catch 블록에서 받은 후 처리
- 적당한 catch 블록을 만나지 못하면 예외처리는 실패
- 정상적으로 처리되면 try-catch 블록을 벗어나 다음 문장 진행
다중 exception handling
- try 블록에서 여러 종류의 예외가 발생할 경우
- 하나의 try 블록에 여러 개의 catch 블록 추가 가능
- 예외 종류별로 catch 블록 구성
- 발생하는 예외를 하나로 처리하기
- 예외 상황 별 처리가 쉽지 않음
- 가급적 예외 상황 별로 처리하는 것 추천 (현업)
- 일단 배울 때는 한 번에 처리해 버려라.. (당장 지금)
try ~ catch ~ finally
- finally 는 예외 발생 여부와 상관없이 언 제 나 실행
- 중간에 return을 만나도 finally 블록을 먼저 수행 후 리턴
try {
// exception이 발생할 만한 코드 - System 자원
} catch(Exception e){
// XX Exception 발생 시 처리 코드
} finally {
// try block에서 접근했던 System 자원의 안전한 원상복구
}
예시 pdf 파일 다시 보기..!
왜 finally를 굳이..?
- try ~ catch ~ finally 로 하나의 세트.
- 여기까지 예외 처리 코드라고 명시적으로 알려주는 문장
- 유지보수성, 가독성 증가.
주요 목적 : try 블록에서 사용한 리소스 반납.
- 반납하지 않으면 장래에 resource leak 발생 가능.
try - with - resources
- JDK 1.7 이상에서 리소스의 자동 close 처리
- try 선언문에 선언된 객체들에 대해 자동 close 호출 (finally 역할)
- 단 해당 객체들이 AutoCloseable interface를 구현할 것
throw 키워드를 통한 위임(짬때리기)
- method에서 처리해야 할 하나 이상의 예외를 호출한 곳으로 전달
- 예외가 없어지는 것이 아니라 단순히 전달됨
- 예외를 전달받은 메서드는 다시 예외 처리의 책임 발생
로그 분석과 예외의 추적
- tHROWABLE의 printStackTrace는 메서드 호출 스택 정보 조회 가능
- 최초 호출 메서드 => 예외 발생 메서드 까지 스택 정보 출력
- 꼭 확인 해야할 정보 3가지..!
- 어떤 예외인가 => 예외 종류
- 예외 객체의 메세지는 무엇인가 => 예외 원인
- 어디서 발생했는가? => 디버깅 출발점
- 직접 작성한 코드를
왜 throw 를 만들었을까요?
- try ~ catch로 그냥 해버리면 될텐데.
throws의 목적과 API 활용
- FileInputStram(String name)
- 문제가 생겼다가 알아서 소멸해버림.
- 개발자 입장에서는 문제가 있는지없는지 몰?루
- 예외 발생 - 예외 전파 - 상황 인지 - 적절한 예외 처리.
- 무책임한 녀석(x) => 통보 해주는 선녀.
메서드 재정의와 throws
- 메서드 재정의 시 조상 클래스 메서드가 던지는 예외보다 넒은 범위의 예외를 던질 수 없다.
- 부모가 치지 않은 사고를 자식이 칠 수 없다.
예외 변환
- 하위 계층에서 발생한 예외는 상위 계층에 맞는 예외로 바꿔서 던져야.
- Exception Changing
- 하위 계층 예외 정보가 상위 계층 예외 디버깅에 유용할 경우
throw => 예외 발생 시킬 때
throws => 던질 때. 런타임 때는 굳이 안 써도 됨.
-----
평가 돌아보기
java에서 String은 불변.
전치연산 후치연산 주의..
클래스 선언 시 그 클래스를 상속받지 못하게 할 목적으로 클래스 앞에 선언하는 Modifier(제한자)는 무엇인가요? => Modifier
13시 - 예외 보충
런타임 이외 에러는 개발자가 손 쓰기 어려운 에러일 수도..
unchecked
- Error
-
if문도 느리지만, try ~ catch는 몇십배 더 느림.
- if 써도 되면 if 써라
자바 클래스 이름은 줄임말 안 쓰는 걸 권장
메서드 오버라이딩 시 부모의 예외 보다 넒은 예외를 넣을 순 없다..
런타임임에도 메소드에 throws가 있다면
- try ~ catch 쓰시오..
예외를 어딘가 넣어서 던저라..?
-----
사용자 정의 예외.
- API에 정의된 exception 이외에 필요에 따라 사용자 정의 예외 클래스 작성
- 대부분 Exception 또는 RuntimeException 클래스를 상속받아 작성.
- 보길 원하기에 런타임 예외 보다는 그냥 예외를 더 많이 사용.
그런데 대부분 if로 예외처리하지 사용자 정의 예외는.. 거의.. 알아는 두자..
B형 알고 대비 조사
buffered Reader
tokenize? 로 짜르고 => Parse.int()...
바르고의 다락방