[자바 마스터북] 6장 예외 공략하기

6.1 예외의 기본

6.1.1 예외의 세 가지 종류

1) 검사 예외 (Exception)

주로 프로그램 작성 시에 예상할 수 있는 비정상 상태를 통지하기 위해 사용.

예를 들어 파입 입출력이 실패할 경우 IOException이 발생하게 되는데 이를 예상하고 미리 어떻게 처리할 지 catch하거나 throw하는 것이다. 이렇게 처리하지 않으면 컴파일 오류가 발생하게 된다.

 

하지만 모든 예외를 포착하게 된다면 정의해야하는 예외 상황이 많아지고 복잡해지므로 '실행 시 예외'로 처리하도록 만들었다.

 

2) 실행 시 예외 (RuntimeException)

주로 프로그램 작성 시에 예상할 수 없는 오류를 통지하기 위해 사용.

'검사 예외'와는 달리 프로그램에서 포착하지 않아도 따로 '컴파일 오류'는 발생하지 않는다.

 

예를 들어 '문자'를 '숫자'로 변환하는 Integer.parseInt의 경우 올바르지 않은 문자가 들어온다해도 컴파일 오류는 발생하지 않는다. 

이는 `실행 시 오류`로 구분하여 실행 중에 포착할 수 있는 예외에 해당한다.

ex) java.lang.NumberFormatException, java.lang.ArithmeticException

 

3) 오류 (Error)

예외와는 달리 시스템의 동작을 계속할 수 없는 "치명적 오류"를 나타낸다. 거의 대부분의 "치명적 오류"는 프로그램에서 포착하는 것이 아니다.. 나중에 설명..

 

6.1.2 예외를 나타내는 세 가지 클래스

1) java.lang.Exception 클래스

검사 예외를 나타내는 클래스. 이 클래스를 계승한 예외(Exception을 계승한 RuntimeException만 제외)는 프로그램 안에서 포착할 수 있다. 따라서 발생하는 메서드 시그니처(선언의 내용)에 throws 절을 기술해야만 한다. 예를 들어 file호출 시 IOException을 명시하거나 sql사용 시 SQLException을 발생시키는 것이 있다.

 

이렇게 하면 예외를 처리하지 않으면 컴파일이 안되므로 좀 더 '견고한 프로그램'을 만들 수 있다는 장점이 있다.

 

2) java.lang.RuntimeException 클래스

실행 시 예외를 나타내는 클래스 프로그램 안에서 반드시 포착할 필요도 throws를 기술할 필요도 없다.

발생한 예외는 자동적으로 호출원에 전파된다. (상위로.. 상위로..)

 

그렇다면 어디에서도 "실행 시 예외"를 포착하지 않는다면 어떻게 될까?

답은 '해당 스레드가 종료해버린다' 이다. Java VM에 예외가 도달하면 해당 스레드를 종료시킨다.

해당 스레드가 메인 스레드라면 애플리케이션 자체가 종료된다.

 

3) java.lang.Error 클래스

'일반적인 애플리케이션에서는 포착해서는 안 되는 중대한 문제'를 나타내는 클래스이다. 

Error는 RuntimeException처럼 따로 catch나 throws 를 기술할 필요가 없다. 하지만 RuntimeException처럼 포착해야 될 대상이 아니다..

 

Error가 발생하는 경우는 그저 애플리케이션이 심각한 비정상 상태이므로 신속하게 프로그램을 종료시켜야 하는 상황이다.

ex) java.lang.OutOfMemeroyError (메모리 부족) -> 신속 종료 필요.

 

6.1.3 예외 처리 세 가지 구문 제대로 사용하기

1) try~ catch~ finallly

try에는 예외가 발생할 수 있는 코드를 catch는 예외에 대한 처리를 finally는 예외와 관계없이 항상 처리해야만 하는 코드를 명시한다.

항상 처리해야하는 것에는 '자원의 반납'이 있다.

 

2) try~with~resources

1)의 방식으로 처리하면 finally 부분에서도 try catch 부분이 생겨 중복이 생기고 귀찮다. 자바 7부터는 try~with~resources 방법을 이용하고 있다. 

try(...자원...) 괄호안에 있는 자원들을 try~catch문이 끝난 후 자동으로 close해준다. 만약 자동으로 처리하는 close에서 예외가 발생한다면 그 외부로 예외가 throw된다.

 

try (InputStream is = new FileInputStream(fromFile);
		OutputStream os = new FileOutputStream(toFile)) {
	is.read(contents);
    os.write(contents);
} catch (IOException ex) {
	// 예외 포착 시 처리
}

 

3) 다중 캐치

try에서는 한 종류의 예외만 발생하지 않는다. try 블록안에서 여러 예외가 발생할 수 있다. 따라서 이를 각각의 상황에 맞게 처리해줘야만 한다.

	try{
            Class<?> clazz = Class.forName("Main");
            clazz.newInstance();
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InstantiationException e) {
            e.printStackTrace();
        }

위 처럼 하면 예외마다 catch문과 처리를 작성해줘야하므로 프로그램이 번잡해진다.

 

자바 7에서 도입된 "다중 캐치"를 이용하면 좀 더 편하게 기술할 수 있다.

        try{
            Class<?> clazz = Class.forName("Main");
            clazz.newInstance();
        } catch (ClassNotFoundException | InstantiationException | IllegalAccessException e) {
            e.printStackTrace();
        }

여기서 중요한 것은 귀찮다고 Exception으로 예외를 포착하고 상위로 예외를 발생시키는 것이다. 이는 공포의 throws Exception 감염 현상을 발생시킨다. 

 

6.2 예외 처리에서 혼란에 빠지지 않기 위한 포인트

6.2.1 오류 코드를 리턴하지 않기

자바에는 예외 처리를 언어에서 제공하므로 비정상적인 상황 시 예외를 날려야하고 예상처럼 정상적으로 수행되었다면 반환값을 제공하면 된다. 이렇게 하면 호출한 쪽에서 불필요한 if문을 작성하지 않아도 된다.

 

6.2.2 예외를 제거하지 않기

예외가 발생해서 프로그램이 종료되는 상황을 방지하기 위해 예외를 catch만 하면 안된다.

그러면 아무것도 수행하고 싶지 않을 땐 어떻게 해야할까? 이 때는 적어도 어떤 예외가 발생했는지는 알려줘야만 한다.

1) 로그 출력을 잊지 않기

catch (NumberFormatException ex) {

    log.warn("숫자가 아닙니다. " + ex);

}

 

위와 같이 어느 부분에서 예외가 발생했는지 알 수 있도록 표현하자.

 

2) 처리를 계속할지 판단하기

처리를 그만두고 상위 메서드를 호출하고 싶다면 return이나 throw를 하고 처리를 계속하고 싶다면 이후에 수행에 필요한 값이 있다면 default값을 넣어 오류가 발생하지 않도록 한다.

 

6.2.3 공포의 throws Exception 감염

복수의 예외가 발생하더라도 예외의 선언이나 포착이 귀찮기 때문에 메서드 시그너처에 throws Exception이라고 기술하는 사람이 있다..

이는 나중에 비극을 낳는다.

 

1) 호출하는 곳에서 Exception을 포착해야한다.

Exception을 메서드에서 던지면 그 메서드를 호출한 호출원은 어떤 예외가 발생했는 지 알지 못하는 상태에서 Exception을 포착해서 처리해야한다.. 어떤 예외인지 알 수 없으므로 예외 처리에 어려움이 생기게 된다.

(호출원에서 예외를 특정할 수 없는 문제 발생)

 

2) 도중에 IOException 등 구체적인 예외가 발생해도 Exception이 되버린다...

현재 진행중인 메서드에서 IOException이나 ClassNotFound등 다양한 예외가 발생할 수 있어도 이를 특정하지 못하고 '호출원'에서는 Exception이라는 정보만 가지고 이를 처리해야한다.. (호출원에서 예외를 특정하지 못함)

 

3) RuntimeException이 발생해도 Exception처럼 처리한다...

Exception과 RuntimeException은 검사예외와 실행 중 예외이므로 분명히 다르다. 하지만 RuntimeException 발생 시에도 Exception으로 던져버리면 Exception 처리로 인식해 적절한 조치를 할 수 없게 된다..

 

6.2.4 어느 계층에서 예외를 포착해서 처리해야 하는가?

* 예외가 발생하는 가능성이 있는 장소

* 처리의 흐름을 판단하는 장소

 

보통 말단에서는 예외를 던지고 그 예외를 받아 전체적인 흐름을 판단할 수 있는 상위 클래스에서 예외를 처리하는 경우가 많다.

 

6.2.5 독자적인 예외 작성하기

별다른 이유가 없다면 자바 표준 API에서 제공하는 예외 클래스를 사용하자.

하지만 예외를 개별적을 처리하는 것이 아닌 통일해서 처리하고 싶은 경우가 있다. 이 때 독자적인 예외를 생성해서 사용하자.

 

Exception이나 RuntimeException을 적절히 상속받아 필요한 필드(id or message 등)을 정의하여 사용하자.

 

6.2.6 예외의 트렌드 

1. 검사예외보다 실행 시 예외를 사용

-> 예외 처리 자체를 간단하게 일일이 개별 로직으로 처리하지 않아도 됨.

 

2. 람다식 안에서 발생한 예외 취급

람다안에서 throw를 하면 람다 밖에서 예외를 처리할 수 있다.

 

3. Optional 클래스 도입에 의한 장점

자바의 고질적인 문제인 NullPointerException을 좀 더 안전하게 처리하기 위해 Optional 클래스가 도입되었다.

Map클래스의 get사용 시 키가 없다면 null을 반환하게 되고 이를 체크하지 않고 사용하면 NullPointerException이 발생했다.

따라서 null체크는 필수적이었다.

 

Optional을 사용하면 개발자가 값을 갖는 경우와 값을 갖지 않는 경우의 코드를 작성하게 된다.