[JAVA] 예외(Exception)처리에 대해

프로그램 오류 

프로그램이 실행중 어떤 원인에 의해서 오작동을 하거나 비정상적으로 종료되는 경우가 있습니다.

이러한 결과를 초래하는 원인을 프로그램 오류라고 합니다. 

 

오류는 발생시점을 기준으로 나누면 "컴파일 에러", "런타임 에러" 로 나눌 수 있습니다.

 

컴파일 에러

말 그대로 컴파일 시점에 발생하는 에러. * Checked 예외

 

런타임 에러 

실행 도중에 발생하는 에러. * Unchecked 예외

 

이 외에도 논리적 에러가 있는데, 논리적 에러는 컴파일도 잘되고 실행도 잘 되지만 개발자가 의도한 것과 다르게 동작하는 에러를 말합니다.
예를 들어, 창고의 재고가 음수가 된다거나 하는 등의 에러

 

자바에서는 실행 시 발생할 수 있는 프로그램 오류를 '에러'와 '예외' 두가지로 구분합니다.

 

에러는 프로그램 코드로 수습할 수 없는 심각한 오류로 예를 들면 메모리 부족(OutofMemeoryError), 스택 오버 플로우(StackOverflowError)가 있습니다. 에러는 일단 발생하면 프로그램 실행중에 복구할 수 없기 때문에 비정상적인 종료를 막을 길이 없지만, 에러와 달리 예외는 개발자가 이에 대해 적절한 코드를 미리 작성해 놓음으로써 프로그램의 비정상적인 종료를 막을 수 있습니다.

 

자바는 실행 시 발생할 수 있는 오류를 클래스로 정의하였습니다.

예외 클래스의 계층구조를 살펴보면 Exception(예외)와 Error(에러)로 나누어져 있습니다.

Exception 클래스는 모든 예외의 조상 클래스 이며, Exception 또한 Checked 예외와 Unchecked 예외로 나누어져 있는 것을 볼 수 있습니다.

 

Chekced / Unchecked Exception

• Unchecked 예외는 실행 도중 발생하는 예외로 RuntimeException을 칭하며, 개발자의 실수에 의해서 발생될 수 있는 예외들로 자바의 프로그래밍 요소들과 관계가 깊은 예외입니다. 
• 중요한 점은 Unchecked 예외 (RuntimeException)는 개발자에 의해 실수로 발생하는 예외이기 때문에 예외에 대한 처리가 강제되지 않는다는 점입니다. 
  • 예를 들면 값의 null인 참조변수의 멤버를 호출하려 했다던지(NullPointerException), 정수를 0으로 나누려고 했다던지 하는 경우에 발생하는 예외(ArithmeticException)가 있습니다.

• Checked 예외는 RuntimeException을 제외한 모든 예외로 프로그램의 사용자들의 동작에 의해서 발생하는 예외
  • 예를 들면 입력한 데이터 형식이 잘못된 형식이거나, 실수로 클래스의 이름을 잘못 적었다던지 하는 경우에 발생하는 예외가 바로 Checked 예외입니다.
  • Checked 에외는 예외에 대한 처리가 강제되기 때문에 개발자는 Checked 예외에 대한 처리를 반드시 해주어야 합니다.

Exception 클래스 : 사용자의 실수와 같이 외적 요인에 의해 발생하는 예외 
RuntimeException 클래스들 : 개발자의 실수로 발생하는 예외 

---

예외 처리 : try-catch(+finally) 문

프로그램 실행도중에 발생하는 예외는 개발자가 이에 대해 미리 처리를 해주어야 합니다. 이를 예외 처리라고 칭합니다.

 

예외 처리의 목적 : 프로그램의 비정상적인 종료를 막고, 정상적인 실행상태를 유지할수 있도록 하기 위함.

 

예외를 처리하기 위해서는 try-catch문을 사용하며, 구조는 이렇습니다.

try{
    /* 예외가 발생할 수 있는 문장 */
}
catch(/* try 문에서 발생한 예외1 */){ /* 예외1에 대한 처리 문장 */ }
catch(/* try 문에서 발생한 예외2 */){ /* 예외2에 대한 처리 문장 */}
catch(/* try 문에서 발생한 예외3 */){ /* 예외3에 대한 처리 문장 */}

try 문에서 발생한 예외와 일치하는 예외가 catch문에 없으면 해당 예외는 처리되지 않습니다.

 

try 블럭 내에서 예외가 발생한 경우 

-  발생한 예외와 일치하는 catch 블럭이 있는지 확인 -> 일치하는 catch블럭 발견 시 블랙 내의 문장 수행 -> try-catch문 빠져나옴.

-  만약 일치하는 catch블럭이 없으면 해당 예외는 처리되지 못하고 빠져나옵니다.

 

try 블럭 내에서 예외가 발생하지 않은 경우

- try-catch문을 빠져나옴.

 

모든 예외의 조상 예외인 Exception을 catch 블럭에 사용하게 되면 어떤 종류의 예외가 발생하더라도 처리하게 됩니다. (다형성)

 

try-catch문 뒤에는 finally를 추가하여 try-catch문에서 예외의 발생여부와 상관없이 실행되어야 할 코드를 작성할 수 있습니다.

try
{
...
}catch(Exception1 e1)
{// Exception1에 대한 처리 문장}
finally{
	// 예외의 발생여부와 관계없이 항상 수행되어야 하는 문장
}

이 경우 예외 발생하면 try->catch->finally 순으로 실행

예외가 발생하지 않으면 try->finally 순으로 실행

---

예외의 printStackTrace(), getMessage() 메소드

예외가 발생했을 때 생성되는 예외 클래스의 인스턴스에는 발생한 예외에 대한 정보가 담겨져 있습니다. 이 정보들은  getMessage()와 printStackTrace()를 통해 시스템 콘솔에 출력할 수 있습니다.

@Test
void printEx() {
    Controller controller = new Controller();
    try {
        controller.request();
    } catch (Exception e) {
        // void
        e.printStackTrace();
        
        // String
        String message = e.getMessage();
        System.out.println("message = " + message);
    }
}

 

이처럼 try-catch문으로 예외가 발생해도 비정상적으로 종료되지 않도록 해주는 동시에 메소드를 통해 예외의 발생 원인을 알 수 있습니다.

---

사용자 정의 예외 만들기

모든 예외의 조상클래스인 Exception을 상속받아 새로운 예외 클래스를 정의할 수 있습니다.

class MyException extends Exception
{
	MyException(String msg) // String을 매개변수로 받는 생성자 msg : 에러메시지
    {
    super(msg); // 조상인 Exception 클래스의 생성자를 호출 
    }
}

 

기존의 예외 클래스는 주로 Exception을 상속받아 Chekced예외로 작성하는 경우가 많았지만, 요즘에는 뒤에서 예외를 처리할 방법중 하나인 예외전환 방법을 사용하기 위해 RuntimeException을 상속받아 작성하는 쪽을 선택하기도 합니다.

---

예외 발생시키기 by throw

키워드 throw를 사용해서 개발자가 고의로 예외를 발생시킬수 있습니다.

 

1. 먼저 연산자 new를 이용해서 발생시키려는 예외 클래스의 객체를 만든 다음

Exception e = new Exception("고의로 발생시킨 예외");

2. throw 키워드를 이용해서 예외를 발생시킵니다.

throw e;

---

발생한 예외를 처리하는 방법에는 3가지 방법이 있습니다.

 

예외 처리 방법

예외처리 방법 1. 예외 복구 try-catch문

public void callCatch()
{
    try {
        repository.call();
    } catch (MyCheckedException e) {
        // 예외 처리 로직
        log.info("예외 처리, message = {}",e.getMessage(),e);
    }
}

/**
 * 내던져진 예외 던지기
 * 체크 예외는 예외를 잡지 않고 밖으로 던지려면 throws 예외를 메소드에 필수로 선언해야함
 * @throws MyCheckedException
 */
public void callThrow() throws MyCheckedException {
    repository.call();
}

• callCatch() : 넘어온 예외를 처리
  • try-catch문을 이용해 try문의 repository.call()에 의해 발생한 예외를 catch 블럭에서 로그를 남기고 끝냄으로써 다른작업 흐름으로 유도했습니다.
  • 해당 예외를 잡아서 복구(처리)했기때문에 throws 키워드를 이용해 예외를 내던질 필요가 없습니다.

---

예외처리 방법 2. 예외 회피 by throws 

예외가 발생한 해당 메소드에서 예외를 처리하지 못하는 경우,

해당 메소드를 호출한 메소드에게 예외를 던짐으로써 해당 메소드에서 예외를 처리하지 못하였음을 알릴 수 있습니다.

예외 중에서도 Checked 예외 일 때는 코드를 통한 예외처리가 필수적이기 때문에 해당 메소드에서 처리하지 못하는 경우 throws 키워드를 이용해 예외를 넘겨주어야 합니다.

Checked 예외는 반드시 처리되거나 넘겨주거나 둘 중 하나 필수.
* RuntimeException(Unchekced 예외)은 넘겨주지 않아도 됩니다.

 

호출한 메소드에게 예외를 넘기기 위해서는 호출된 해당 메소드 뒤에 throws 키워드와 함께 해당 메소드에서 발생한 예외 혹은 해당 메소드가 호출한 메소드가 처리하지 못해서 넘어온 예외 를 작성해 주면 됩니다.

 

public void callCatch()
{
    try {
        repository.call();
    } catch (MyCheckedException e) {
        // 예외 처리 로직
        log.info("예외 처리, message = {}",e.getMessage(),e);
    }
}

/**
 * 내던져진 예외 던지기
 * 체크 예외는 예외를 잡지 않고 밖으로 던지려면 throws 예외를 메소드에 필수로 선언해야함
 * @throws MyCheckedException
 */
public void callThrow() throws MyCheckedException {
    repository.call();
}

• callThrow() : 넘어온 예외를 처리하지 못하고 던지기
  
  • repository.call()에서 발생한 예외를 메소드 뒤에 throws 키워드 + 넘겨받은 예외를 작성해 자신 또한 처리하지 못하였음을 알리고 callThrow()를 호출한 메소드에게 예외를 던집니다.

+ try-catch문과 throws 키워드를 모두 이용하여 현재 메소드와 호출한 메소드에서 예외를 나누어서 처리하도록 할 수 있습니다.

public void excute1() throws Exception1
{
    try
    {
        repository.call(); // Exception1 , Exception2 발생 
    }
    catch(Exception2 e)
    {
        // repository.call()에서 넘겨받은 Exception2 처리
    }
}

---

예외 처리방법 3. 예외 전환하기

Unchecked 예외 (RuntimException) 은 예외처리가 강제되지 않는다고 했었습니다.

• 체크 예외 : 예외를 잡아서 처리하지 않으면 반드시 throws에 던지는 예외를 선언해야 함.
• 언체크 예외 : 예외를 잡아서 처리하지 않아도 throws 생략 가능. ( 처리 강제성 X )

Unchecked 예외는 신경쓰고 싶지 않은 예외들을 무시할 수 있기 때문에, throws 예외를 생략할 수 있을 뿐만 아니라, 신경쓰고 싶지 않은 예외의 의존관계를 참조하지 않아도 된다는 장점이 있습니다.

 

 

Chekced 예외의 경우

각 메소드가 예외를 처리하지 못하고 넘겨줄 때 메소드 모두 throws 예외에 의존하고 있습니다.  

만약 JDBC 기술에서 JPA 기술로 바꾼다면 SQLException에 의존하던 모든 서비스, 컨트롤러를 JPAException에 의존하도록 고쳐야 합니다. 

logic() throws SQLException ▶︎ logic() throws JPAException

* throws Exception으로 통일하게 되면 다른 체크예외를 체크할수 있는 기능이 무효화되기 때문에 권장되지 않습니다.

 

이럴 때 사용하는 방법이 예외 전환입니다. (Checked 예외를 Unchecked 예외로 전환)

static class Service
{
    NetworkClient networkClient = new NetworkClient();
    Repository repository = new Repository();

    public void logic(){
        repository.call();
        networkClient.call();
    }
}

static class NetworkClient
{
    public void call(){
        // Unchecked exception 내던지기
        throw new RuntimeConnectException("연결 실패"); // extends RuntimeException
    }
}

static class Repository {
    public void call() {
        try {
            runSQL(); // SQLException ( Chekced Exception ) 발생 
            // catch문에서 체크 -> 언체크(런타임) 변경해서 내던지기
        } catch (SQLException e) {
            throw new RuntimeSQLException(e); // extends RuntimeException
        }
    }

    private void runSQL() throws SQLException {
        throw new SQLException("ex");
    }
}

 

try - catch문을 이용해 try문에서 발생한 Checked예외를 catch문에서 Unchecked예외로 변경해서 던져주었습니다.

예외전환 방식 적용

• 예외전환 방식을 사용해 Unchecked 예외로 변경해서 던졌기 때문에, 서비스계층의 logic() 메소드에서는 throws 키워드를 생략해 이제 더 이상 throws 예외에 의존하지 않게 됩니다.
• 따라서 SQLException에 의존하지 않게 되어 JDBC에서 JPA 기술로 변경되어도 서비스 계층의 코드를 수정할 필요가 없어졌습니다.

예전에는 Chekced예외를 자주 사용했지만 throws 키워드를 붙여주어야 하는 번거로움 때문에 최근 라이브러리들은 대부분 Unchecked (런타임예외) 를 기본으로 제공한다고 합니다.

* Make an instance managed and persistent.
   * @param entity  entity instance
   * @throws EntityExistsException if the entity already exists.
   * @throws IllegalArgumentException if the instance is not an
   *         entity
   * @throws TransactionRequiredException if there is no transaction when
   *         invoked on a container-managed entity manager of that is of type
   *         <code>PersistenceContextType.TRANSACTION</code>
   */
public void persist(Object entity);

  /**
   * Issue a single SQL execute, typically a DDL statement.
   * @param sql static SQL to execute
   * @throws DataAccessException if there is any problem
   */
  void execute(String sql) throws DataAccessException;

 

+ 하지만 런타임에러는 명시를 해놓지 않으면 어떤 예외가 발생할 지 코드를 읽는 개발자 입장에서 어려움을 느낄 수 있습니다.

그럴 때에 메소드에서 발생할 수 있는 예외를 문서로 명시해 주거나 + 코드에도 throws 로 명시해주는 것이 중요합니다.

 

 

static class Repository {
    public void call() {
        try {
            runSQL();
            // catch문에서 체크 -> 언체크(런타임) 변경해서 내던지기
        } catch (SQLException e) {
            throw new RuntimeSQLException(e);
        }
    }

+ 예외를 전환할 때에는 반드시 기존예외를 포함해서 스택 트레이스를 남기도록 합시다. 스택 트레이스를 남겨야 변환되기 전의 예외(SQLException)를 확인할 수 있습니다.

스택 트레이스 로그

---

<참고자료>

https://www.nextree.co.kr/p3239/

Java 예외(Exception) 처리에 대한 작은 생각

https://velog.io/@gillog/Java-Exception-Handling%EB%B3%B5%EA%B5%AC-%ED%9A%8C%ED%94%BC-%EC%A0%84%ED%99%98

[Java] Exception Handling(복구, 회피, 전환)

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-1/dashboard

스프링 DB 1편 - 데이터 접근 핵심 원리 - 인프런 | 강의