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

+ Recent posts