1. java.lang.Trowable
ㄱ. Error : 프로그램 실행 중 일어날 수 있는 치명적인 오류. 복구 불가능
ㄴ. Exception : 에러보다 비교적 경미한 오류. 프로그램의 비정상적 중단을 막을 수 있음
a. RuntimeException
b. Exception
2. RuntimeException
코드 논리의 오류. 컴파일시 체크되지 않고, 실행 도중 예외 발생시 비정상적으로 종료됨
코드를 수정하여 예외 발생을 막을 수 있음
대부분의 런타임 예외는 실행 중 조건의 문제보다는 코드의 논리적인 오류의 경우에 의해 발생함
1
2
3
4
5
6
7
8
9
10
11 |
package spms.test;
public class TestMain {
public static void main(String[] args) {
int x = 10;
int y = 0;
int z = x / y; //0으로 나눈 값이기 때문에 논리적 오류가 발생함
System.out.println("debug> z : " + z);
}
} |
cs |
3. Exception
실행 도중 필요한 리소스 파일이 없거나, 사용 매체의 문제 등으로 발생하는 예기치 못한 예외들
자바는 try ~ catch 문으로 예외 처리를 해야만 컴파일을 성공시킨다
try문에서 예외 발생시 JVM(Java Virtual Machine)은 그 예외가 어떤 것인지 분석하고 그 예외를 담을 수 있는 객체를 만들어서 참조함
=> catch 문은 try문에서 발생한 예외 객체를 인자로 받아와 catch문 내에서 사용
* Exception과 Error를 구분하는 기준 : JVM의 겉과 속
ㄱ. 겉 : Exception
ㄴ. 속 : Error
* try ~ catch 문에 return이 있다 하더라도 finally문은 반드시 실행된다
* 런타임 예외가 아닌 Exception일 경우 컴파일러는 에러를 발생시킨다
* 한 개의 try문에서 여러 개의 예외가 발생할 시에는 여러 개의 catch를 사용한다
=> 첫 번째 catch문에서 예외의 최상위인 Exception 매개변수를 받게 되면, 두 번째 catch문 부터는 받을 예외가 없어 컴파일 에러가 발생하게 됨
* 자바 7.0부터 지원하는 다중 catch 방식
A와 B Exception이 발생했을 때, 동일한 문구를 출력해야 함에도 불구하고 각각의 catch를 써야 함 => 중복 발생
1
2
3
4
5
6
7
8
9 |
try {
//예외 발생
} catch (AException e) {
System.out.println("예외 발생!");
} catch (BException e) {
System.out.println("예외 발생!");
} catch (CException e) {
e.printStackTrace();
} |
cs |
<중복 예외를 처리하던 기존 자바 코드>
1
2
3
4
5
6
7 |
try {
//예외 발생
} catch (AException || BException e) {
System.out.println("예외 발생!");
} catch (CException e) {
e.printStackTrace();
} |
cs |
<자바 7.0부터 지원하는 다중 catch 방식>
4. Finally
* finally를 가장 잘 활용하는 사례 : IOStream / DB Connection
ㄱ. IO (Input Output) Stream
가비지 컬렉션의 대상이 아닌 것 (가비지 컬렉션 : 자바의 JVM에서 모든 객체를 자동으로 소멸시켜주는 기능)
=> IO Stream 객체들은 개발자가 직접 닫아줘야 함
* IO Stream 객체 생성 후, 사용 중 에러가 발생하여 프로그램을 종료시 가비지 컬렉터의 대상이 아니기 때문에 메모리 누수의 원인이 될 수 있음
=> finally 블록을 꼭 추가하고 블록 안에서 IO Stream 객체를 소멸시키는 코드를 넣어야 함
5. Throw
DB 서버를 연결시 DB 서버에서 접속했다가 사용을 끝내면 자동 접속 종료를 기다리기 전에 편의상 미리 닫아주는 것이 효율적일 때가 있음. 그럴 때 사용
ㄱ. throw : 개발자가 필요에 의해 강제로 발생시키는 예외 코드
메소드 내에서 상위 블럭으로 예외를 던짐
억지로 에러를 발생시킬 때에도 사용하지만, 현재 메소드 에러를 처리한 후 상위 메소드에 여러 정보를 줌으로서 상위 메소드에도 에러가 발생했다는 것을 감지할 수 있음
throw 에약어 뒤에 java.lang.Throwable 클래스를 상속 받은 자식 클래스의 객체를 지정해야 함
1
2
3
4
5
6
7
8
9 |
try {
//예외를 처리하는 객체 메모리 생성
Exception e = new Exception(" ");
//JVM이 예외를 감지하도록 고의로 이벤트를 발생시킴
throw e;
} catch (Exception e) {
//예외처리 코드
} |
cs |
ㄴ. throws : 현재 메소드에서 상위 메소드로 예외를 던짐
첫 번째 메소드에서 예외 발생시 예외를 처리해버리면 그 후의 메소드들은 예외가 발생되었는지조차 모르기 때문에 자바에서는 throws 키워드를 사용함
예외를 자신이 처리하지 않고, 자신을 호출하는 메소드에게 책임을 전가함
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 |
void test1() throws Exception {
//예외를 발생시키는 코드
}
void test2() throws Exception {
}
void test3() {
try {
test2();
}
catch (Exception e) {
//예외를 처리하는 코드
}
} |
cs |
* 메소드 오버라이딩시 throws 예외처리
- 예외를 던지지 않거나
- 부모메소드보다 작거나 같은 범위에서 예외처리를 해야 함
(부모 메소드가 예외처리 되지 않은 상태인 경우 오버라이딩 된 메소드도 예외 처리를 할 수 없음)
'BackEnd > Java' 카테고리의 다른 글
Java :: startsWith() vs indexOf() vs charAt() (0) | 2016.12.26 |
---|---|
Java :: Reflection 리플렉션 (0) | 2016.12.18 |
Servlet :: ServletContext vs ServletConfig (0) | 2016.11.22 |
Java :: Abstract vs Interface (0) | 2016.10.28 |
Java :: 간단한 JDBC 예제 (0) | 2016.10.18 |