예외 처리의 다양한 방법

개발자가 가장 신경쓰기 귀찮은 영역, 예외처리에 대해 알아보자.

 

 

# 예외 종류와 특징

2021.07.07 - [Backend/Java] - #7 Exception (예외처리)

#7 Exception (예외처리)

• Error
  자바 프로그램 밖에서 발생한 예외. 프로세스에 영향, 더 이상 실행 불가능
  보통 메모리가 부족하거나 가상머신 자체의 문제로 앱 상에서 예외처리가 불가능하다.
  => 신경쓰지말자, 개발자의 영역이 아니다
  
  
• Runtime Exception (= unchecked Exception)
  런타임시에 발생한 예외. 컴파일 단계에서 확인할 수 없어 unchecked라고도 부른다.
  => 예외처리를 강제하지 않는다. 피할 수 있지만 부주의로 인해 발생할 수 있다.
  
  
• Checked Exception
  컴파일 단계에서 확인 가능한 예외들.
  => catch를 잡든지, throws로 다시 던지던지 반드시 잡아서 처리하자!

 

 

# 예외 블랙홀

try {
	...
} catch (Exception e) {
	// 아무일도 하지 않는다. 프로그램만 안멈추면 되는거지! 암!
}

...
}catch (SQLException e){
    System.out.println(e); // 콘...솔?
    e.printStackTrace(); // 이건 사용하면 안되는 메서드이다!
}

 

• Thread-Safety하지 않은 코드이다
• 콘솔 IO를 이용하면 단위테스트, 독립적인 테스트가 불가능하다.
• 콘솔 IO는 비용이 비싸고, 리다이렉션 될 수 있으며, 보안상 좋지 않다.

그나마 이건 양호한 편이다. 심한 경우 throws로 무책임하게 다 던져버리는 습관을 가진 개발자도 있다.

// 아 몰라~ 니가 알아서 처리하세요. 난 예외 무시할란다
public void method1() throws Exception {
    method2();
}

public void method2() throws Exception {
    method3();
}

public void method2() throws Exception {
    ...
}

 

 

# 다양한 예외 처리방법

• 예외 복구
  문제를 해결해서 정상 상태로 돌려놓기
  
  
• 예외 처리 회피
  예외를 자신이 담당하지 않고, 자신을 호출한 쪽으로 던져버리는 것(throws)
  - 무의미하게, 무책임하게 던지는 것이 아니다. 역할에 따른 분담이다.
  
  
• 예외 전환
  예외를 밖으로 던진다는 것은 회피와 비슷하지만, 그대로 넘기지 않고 적절한 예외로 전환해서 던짐.
  - 로우 레벨에서 발생한 예외를 서비스 계층에서 의미를 분명하게 하기 위해 (추상화된 예외로 만듬.)
  - 예외 처리를 단순하게 하기 위해 포장

 

DAO 에서 발생한 SQLException이 웹 컨트롤러 메서드까지 의미있게 전달된다 해서 무슨 소용이 있을까? 반대로 웹 컨트롤러 메서드에 throws SQLException이 달려있으면 이를 도대체 어떻게 해석하고 사용해야할까? 이처럼 스스로 복구가 불가능한 예외라면, 빠르게 런타임 예외로 포장해서 던지는 것이 맞다. 다른 계층의 메서드에서 불필요하게 throws 선언을 들어가지 않게 해주자.

• 어플리케이션 로직상 예외조건이 발견되거나 예외상황이 발생한다면 체크 예외를 사용하는것이 적절하다. 적절한 대응이나 복구 작업이 필요하기 때문이다.
• 하지만 어차피 복구하지 못할 예외라면 런타임 예외로 포장해서 던져버려서 관리자(예외처리 서비스, 로그 객체)에게 알리는 것이 바람직하다.

 

 

# 런타임 예외의 보편화

자바 환경이 서버로 이동하면서, 체크 예외의 활용도와 가치는 점점 떨어지고 있다. 예전에는 복구할 가능성이 조금이라도 있다면 체크 예외로 만들었는데, 지금은 100% 복구할 수 있는 예외가 아니라면 런타임(언체크)예외로 만드는 경향이있다.

sda

자바가 처음 만들어질 떄 사용되던 애플릿, AWT, Swing 같은 독립형 프로그램에서는 통제 불가능한 시스템 예외라고 할지라도 작업이 중단되지 않게 복구해야했다. 지금 실행중인 프로그램이 사용자 파일을 찾을 수 없다고 종료시켜버릴 순 없으니까 말이다.

 

하지만 자바 서버환경은 다르다. 수많은 사용자가 동시에 요청을 보내고 각 요청은 독립적인 작업으로 취급된다. 하나의 요청을 처리하는 중 예외가 발생하면, 작업을 중단시키면 그만이다. 만약 프로그램 자체의 오류이거나 외부 환경으로 인해 예외가 발생한 경우라고 하더라도 작업을 취소하고 서버 관리자나 개발자에게 통보해주는 편이 더 낫다.

 

 

# 어플리케이션 예외

반면에 시스템 또는 외부상황이 원인이 아니라, 어플리케이션 로직에 의해 의도적으로 발생시키고 반드시 catch해야하는 예외도 있다. 이를 보통 어플리케이션 예외라고 부른다.

 

예를 들어 사용자가 요청한 금액을 은행계좌에서 출금하는기능을 가진 메서드가 있다고 생각해보자. 만약 현재 잔고를 넘는 금액을 출금하고자 한다면, 작업을 중단시키고 적절한 조치를 취해야 할 것이다.

1. 잔고 부족이 발생했을 경우 다른 리턴값(-1)을 반환한다.
   - 일관된 예외 상황에서, 반환값에 대한 정책이 완벽하게 공유되어야하고 로직 흐름이 복잡해진다.
   
   
2. 정상적인 흐름을 따르는 코드는 그대로 두고, 비즈니스적인 의미를 띤 예외를 던진다.
   - 이게 바로 어플리케이션 예외이다. 개발자에게 catch를 강요한다.
   - 예를 들어 잔고부족인 경우 InsufficientBalanceException 같이 추상화 된 예외를 던지도록 설계한다.

 

 

# DAO 기술에서 추상화된 예외를 제공하는 이유?

예외 포장 예시 - JdbcTemplate

SqlException( 체크 예외 )를 포장해서 DataAccessException( 런타임 에외, 언체크 )로 추상화된 예외로 포장하고있다. 

public<T> T execute(ConnectionCallback<T> action)throws DataAccessException{
        Assert.notNull(action,"Callback object must not be null");

        Connection con=DataSourceUtils.getConnection(obtainDataSource());
        
        try{
            Connection conToUse=createConnectionProxy(con);
            return action.doInConnection(conToUse);
        } catch(SQLException ex){ // 저수준이 SQLException을 포장
            String sql=getSql(action);
            DataSourceUtils.releaseConnection(con,getDataSource());
            con=null;
            // 예외를 포장할 땐 이렇게 기존의 예외(ex)를 중첩하는게 좋다.
            throw translateException("ConnectionCallback",sql,ex);
        } finally{
            DataSourceUtils.releaseConnection(con,getDataSource());
        }
}

스프링이 왜 이렇게 DataAccessException 같이 추상화된 예외를 만들어서 사용하는지 생각해보자. 예외를 포장하여 추상화함으로서 데이터 엑세스 기술(SQLException)에 의존적인 코드를 작성하지 않게 만들 수 있다.

public void add(User user) throws SQLException; //Jdbc api 계층
public void add(User user) throws PersistentException; //JPA 계층
public void add(User user) throws HibernateException; //Hibernate 계층

 

 

# 정리

• 예외를 잡아서 아무런 조취를 취하지 않거나 의미 없는 throws 선언을 남발하는 것은 위험하다.
• 예외는 복구하거나, 예외처리 오브젝트로 의도적으로 전달하거나, 적절한 예외로 전환해야 한다.
• 좀 더 의미 있는 예외로 변경하거나, 불필요한 catch/throws를 피하기 위해 런타임 예외로 포장하는 두 가지 방법의 예외 전환이 있다.
• 복구할 수 없는 예외는 가능한 빨리 런타임 예외로 전환하는 것이 바람직하다.
• 애플리케이션의 로직을 담기 위한 예외는 체크 예외로 만든다.
• JDBC의 SQLException은 대부분 복구할 수 없는 예외이므로 런타임 예외로 포장해야 한다.
• SQLExcetion의 에러 코드는 DB에 종속되기 때문에 DB에 독립적인 예외로 전환될 필요가 있다.
• 스프링은 DataAccessException을 통해 DB에 독립적으로 적용 가능한 추상화된 런타임 예외 계층을 제공한다.
• DAO를 데이터 엑세스 기술에서 독립시키려면 인터페이스 도입과 런타임 예외 전환, 기술에 독립적인 추상화된 예외로 전환이 필요하다.