Exception에 관하여

출처: http://babtingdev.tistory.com/302

 try { 
   ...
} catch (SQLException e) {} 

보통 예외를 잡고는 아무것도 하지 않는 이러한 코드를 많이 작성한다. 예외 발생을 무시해 버리고 정상적인 상황인 것처럼 다음 라인으로 넘기겠다는 분명한 의도가 있는게 아니라면 연습 중에도 절대 만들어서는 안되는 코드이다.
이것은 예외가 발생하는 것보다도 훨씬 안좋은 상황을 만든다. 오류가 있는 건데 오류를 무시하고 계속 진행해버리기 때문이다.

try {
   ...
} catch(SQLException e) {
   System.out.println(e);
}

try {
   ...
} catch(SQLException e) {
   e.printStackTrace();
}

위 두개도 마찬가지로 사용해선 안될 코드들 이다. 예외는 처리되어야 한다.

예외를 처리할 때 반드시 지켜야 할 원칙은 한가지 이다. 모든 예외는 적절하게 복구되던지 아니면 작업을 중단시키고 운영자 또는 개발자에게 분명하게 통보되야 한다.

무의미하고 무책임하게 throws를 사용하는 개발자들도 있다. 처리하기 귀찮으니 그냥 메소드 선언부에 throws 를 써서 넘겨버리는 것이다. (아래 코드와 같이.)
public void method1() throws Exception {
}
try~catch로 Exception을 삼켜버리는 코드보다야 낫지만 무작정 throws 를 남발하는 이 방법도 매우 안좋은 방법이다. 


예외의 종류와 특징에 대해 알아보자.
1. Error 
java.lang.Error 클래스의 서브클래스들이다. 에러는 시스템에 뭔가 비정상적인 상황이 발생했을 경우에 사용된다. 그래서 주로 자바VM에서 발생시키는 것이고 어플리케이션 코드에서 잡으려고 하면 안된다. OutOfMemoryError나 ThreadDeath같은 에러는 catch블록으로 잡아봤자 대응 방법이 없기 떄문이다.

2. Exception
java.lang.Exception 클래스와 그 서브클래스로 정의되는 예외들은 개발자들이 만든 어플리케이션 코드의 작업중에 예외상황이 발생했을 경우에 사용된다.
Exception은 체크예외와 언체크 예외로 구분된다. 언체크 예외는 Exception의 서브클래스이며 RuntimeException클래스를 상속받은 클래스이며 체크 예외는 RuntimeException클래스를 상속받지 않은 나머지 Exception의 서브클래스들이다.

2.1 체크예외
체크예외는 무조건 처리되어야 하는 예외이다. try~catch, throws를 통해 어떻게든 처리를 하지 않으면 컴파일 에러가 난다.
IOException이나 SQLException이 대표적이다.

2.2 언체크/런타임 예외
java.lang.RuntimeException 클래스를 상속한 예외들이며 명시적인 예외처리를 강제하지 않는다. (try~catch, throws등의 처리를 안해도 컴파일 에러가 안난다는 의미.)
물론 명시적인 처리를 하는 것도 가능하다. 
런타임 예외는 주로 프로그램의 오류가 있을 때 발생하도록 의도된 것이다. NullPointerException이나 IllegalArgumentException등이 대표적이다. 피할 수 있지만 개발자가 부주의 해서 발생할 수 있는 경우에 발생하도록 만든 것이 런타임 예외이다. 따라서 런타임 예외는 예상하지 못했던 예외상황에서 발생하는게 아니기 떄문에 명시적인 처리를 하지 않아도 되게 만든 것이다.

이제 예외를 처리하는 방법에 대해 알아보자.

1. 예외복구
예외상황을 파악하고 문제를 해결해서 정상상태로 돌려놓는 것이다. 예를 들면 읽으려는 파일이 없을때 IOException이 발생할 것이다. 이 예외가 발생한 상황을 다른 파일을 읽도록 안내하는 걸로 해서 예외상황을 해결할 수 있다.

2. 예외처리 회피
예외처리를 자신이 담당하지 않고 자신을 호출한 쪽으로 던져버리는 것이다. 
public void add() throws SQLException {
}

public void add() throws SQLException {
   try {
      ...
   } catch(SQLException e) {
      throw e;
   }
}
하지만 이 방법은 무책임한 책임회피가 될 수 있다. 예를 들어 DAO가 SQLException을 생각없이 던졌다면?
DAO를 사용하는 서비스 계층이나 웹 컨트롤러에게 이 SQLException이 전달 될 것이다. 과연 서비스 계층이나 웹 컨트롤러 계층에서 이 SQLException을 처리하는게 맞는 것인가? 처리는 할 수 있나? 아마 이 예외는 그냥 처리되지 않고 서버로 던져지게 될 것이다.
예외를 회피하는 것은 예외를 복구하는 것처럼 의도가 분명해야 한다. 예외를 회피하는 것은 자신을 호출해서 사용하는 쪽에서 이 예외를 다루는게 최선의 방법이라는 확신이 있을 경우에만 사용하도록 한다.

3. 예외 전환
예외 회피와 비슷하게 예외를 복구해서 정상적인 상태로 만들 수 없는 경우 예외를 메소드 밖으로 던진다. 하지만 예외회피와는 달리 발생한 예외를 그냥 던지는 것이 아니라 적절한 예외로 전환해서 던진다.
첫째는 내부에서 발생한 예외를 그대로 던지는 것이 그 예외 상황에 대한 적절한 의미를 부여해주지 못하는 경우, 의미를 분명하게 해줄 수 있는 예외로 바꿔주기 위해서이다.
예를 들면 사용자를 DB에 insert하다가 동일한 id가 있어 에러가 났다고 하자. JDBC API는 SQLException을 발생시킨다. 이 경우 DAO가 그냥 SQLException을 던지면 이를 이용하는 서비스 계층에서는 무슨 의미인지 파악하기 힘들 것이다. 이런 경우 SQLException을 DuplicatUserIdException 같은 예외로 바꿔서 던져주는게 좋다.

catch(SQLException e) {
   if(e.getErrorCode() == MysqlErrorNumbers.ER_DUP_ENTRY)
      throw DuplicateUserIdException();
   else 
      throw e;
}

보통 예외를 전환해서 던져줄때에는 원래 발생한 예외를 담아서 중첩예외로 만드는 것이 좋다.
중첩 예외로 만들었을 경우에는 getCause() 메소드를 이용해서 처음 발생한 예외가 무엇인지 확인할 수 있기 때문이다.
생성자나 initCause()메소드로 근본 원인이 되는 예외를 넣어주면 된다.

catch(SQLException e) {
    throw DuplicationUserIdException(e);
}

catch(SQLException e) {
    throw DuplicationUserIdException().initCause(e);
}

예외전환을 사용하는 경우는 위의 경우도 있지만 주로 예외처리를 강제하는 체크 예외를 예외처리를 강제하지 않는 런타임 예외로 바꾸는 경우에 사용한다.
DAO에서 발생한 SQLException이 웹 컨트롤러까지 전달이 된다고 해서 무슨 소용이 있을까? 웹 컨트롤러의 메소드에 throws SQLException이 선언되어 있다면 이를 어떻게 해석해야 할까? 어차피 복구가 불가능한 예외라면 가능한 빨리 런타임 예외로 포장해 던지게 해서 다른 계층의 메소드를 작성할 때 불필요한 throws 선언이 들어가지 않게 해야한다. DAO에서 발생한 SQLException이지 웹컨트롤러와는 사실 상관이 없는 예외이기 때문에 헷갈릴만한 상황을 만들면 안된다.
어차피 복구하지 못할 예외라면 어플리케이션 코드에선 런타임 예외로 포장해서 던지고, 예외처리 서비스 등을 이용해 자세한 로그를 남기고, 관리자에게 메일을 전송하고 사용자에겐 안내메시지를 보여주는 것도 처리 방법이다.


자바가 처음 만들어 질때는 AWT, Swing 등을 사용해서 독립형 어플리케이션을 개발했었다. 이때는 사용자가 입력한 이름에 해당하는 파일을 찾을 수 없다고 어플리케이션이 종료가 되면 안되었었다. 어떻게든 처리를 했어야 했다.
하지만 자바 엔터프라이즈 서버 환경은 다르다. 수많은 사용자가 요청을 보내고 각 요청들이 독립적인 작업으로 취급된다. 요청을 처리하다 예외가 발생하면 해당 작업만 중단시키면 된다. 독립형 어플리케이션과는 달리 서버의 특정 계층에서 예외가 발생했을 때 작업을 일시 중지하고 사용자와 바로 커뮤니케이션하면서 예외상황을 복구할 수 있는 방법은 없다.

최근에 등장하는 표준스펙 또는 오픈소스 프레임웍에서는 API가 발생시키는 예외를 체크예외 대신 언체크 예외로 정의하는 것이 일반화되고 있다. 예전에는 복구할 가능성이 조금이라도 있다면 체크예외로 만든다고 생각했는데 지금은 항상 복구할 수 있는 예외가 아니면 일단 언체크/런타임 예외로 만드는 경향이 있다.

체크예외를 언체크/런타임 예외로 만드는걸 구현해보자. 대표적인 체크예외가 SQLException이다. 그 중 동일한 pk를 
입력했을때 에러가 발생해서 SQLExcepion이 나는 상황을 구현해 보겠다.

일단  동일한 pk가 입력이 되었을 경우 사용할 RuntimeException을 상속받은 DuplicateKeyException 을 만들어 보자.
public class DuplicateKeyException extends RuntimeException {
   public DuplicateKeyException(Throwable cause) { // 중첩 예외를 만들기 위해 생성자를 만들어 이용.
      super(cause);
   }
}

이제 add() 메소드를 구현해 보겠다.
public void add() throws DuplicateKeyException {
    try {
         ...
    } catch(SQLException e) {
         if(e.getErrorCode() == MysqlErrorNumbers.ER_DUP_ENTRY) // Mysql 일 경우.
              throw new DuplicateKeyException(e); // 예외 포장
         else 
              throw new RuntimeException(e);
    }
}

RuntimeException을 사용하게 되면 꼭 예외 처리가 필요한 경우는 놓칠 수도 있게 된다. 반드시 예외를 catch해서 조치를 취하도록 요구하는 예외를 일반적으로 어플리케이션 예외라고 한다.
흔히 에러가 났을 경우 처리하는 작업이 특정 코드값을 정해서 리턴하는 방법이 있다. 
0이면 에러, 1이면 정상 이런 식으로...
이 방법은 각 코드값들을 명확하게 정리를 잘 해놓지 않으면 흐름을 파악하고 이해하기 어려워진다.
두번째 방법은 오류 발생시 비즈니스적인 의미를 띈 예외를 던지도록 하는 것이다. 물론 각 예외들은 위에 설명한 중첩방식같이 별도로 구현해서 사용을 해야 한다. 이 방법은 정상적인 흐름은 try {}안에 모아놓고 예외상황에 대한 코드들은 catch{}로 분리시킴으로 인해 깔끔하게 정리가 된다. 그리고 예외의 이름만 봐도 코드가 이해하기 편해지는 장점이 있다.