
1. 예외처리
1.1 프로그램 오류
에러 (오류) : 프로그램이 실행 중 어떤 원인에 의해서 오작동을 하거나 비정상적으로 종료되는 원인
에러는 발생 시점에 따라 '컴파일 에러' 또는 '런타임 에러'로 나눌 수 있다.
- 컴파일 에러 : 컴파일 시에 발생하는 에러
- 런타임 에러 : 실행 시에 발생하는 에러
- 논리적 에러 : 실행은 되지만 의도와 다르게 동작하는 것
컴파일을 에러 없이 성공적으로 마쳤다고 해도 프로그램 실행 시에도 에러가 발생할 수 있다. 컴파일러를 통해 소스 코드의 기본적인 사항은 컴파일 시에 모두 걸러 줄 수 있지만 실행 도중에 발생할 수 있는 잠재적인 오류까지는 검사할 수 없다. 이런 런타임 에러를 방지하기 위해서 프로그램의 실행 도중 발생할 수 있는 모든 경우의 수를 고려하여 대비가 필요하다. 자바에서는 실행 시 발생할 수 있는 프로그램 오류를 에러(error)와 예외(exception)으로 구분할 수 있다.
- 에러 : 프로그램 코드에 의해서 수습될 수 없는 심각한 오류 (메모리부족, 스택오버플로우 등)
- 예외 : 프로그램 코드에 의해서 수습될 수 있는 다소 미약한 오류 (프로그래머가 이에 대한 적절한 코드를 미리 작성해 놓으면 비정상적인 종료를 막을 수 있음)
1.2 예외 클래스의 계층 구조
자바에서는 실행 시 발생할 수 있는 오류(에러와 예외)를 클래스로 정의했다. 모든 클래스의 조상은 Object클래스이므로 Exception과 Error 클래스 역시 Object 클래스의 자손이다.

모든 예외의 최고 조상은 Exception 클래스이며, RuntimeException의 자손으로 많은 Exception class (ClassCastException, NullPointerException, IndexOutOfBoundsException 등)를 가지고 있다. 예외 클래스들은 다음과 같이 두 그룹으로 나눠질 수 있다.
- 1) Exception 클래스와 그 자손들 (RuntimeException과 자손들 제외)
- 2) RuntimeException 클래스와 그 자손들
이후 2는 RuntimeException클래스들 이라고 부르고, 1은 Exception클래스들이라고 부른다.
RuntimeException 클래스들은 주로 프로그래머의 실수에 의해서 발생될 수 있는 예외들이고 자바의 프로그래밍 요소들과 관계가 깊다. ArrayIndexOutOfBoundsException, NullPointerException, ClassCastException(형변환 오류), ArithmeticException(정수를 0으로 나누려고 하는 경우) 등이 있다.
Exception 클래스들은 주로 외부의 영향으로 발생할 수 있는 것들로서 프로그램의 사용자들의 동작에 의해서 발생하는 경우가 많다. 예를 들면 FileNotFoundException(존재하지 않는 파일의 이름을 입력), ClassNotFoundException, DataFormatException(입력한 데이터 형식이 잘못된 경우) 가 있다.
1.3 예외 처리하기 - try-catch 문
예외처리란 프로그램 실행 시 발생할 수 있는 예기치 못한 예외의 발생에 대비한 코드를 작성하는 것이며, 예외처리의 목적은 예의의 발생으로 인한 실행 중인 프로그램의 갑작스런 비정상 종료를 막고 정상적인 실행상태를 유지할 수 있도록 하는 것이다.
발생한 예외를 처리하지 못하면 프로그램은 비정상적으로 종료되며 처리되지 못한 예외는 JVM의 예외 처리기가 받아서 예외의 원인을 화면에 출력한다.
예외 처리를 위한 try-catch 문의 구조는 다음과 같다.
try{
// 예외가 발생할 가능성이 있는 문장들을 넣는다
} catch (Exception1 e1) {
// Exception1 발생 시 처리하기 위한 문장
} catch (Exception2 e2) {
// Exception2 발생 시 처리하기 위한 문장
} catch (Exception3 e3) {
// Exception3 발생 시 처리하기 위한 문장
}
하나의 메서드 내에 여러 개의 try-catch문이 사용될 수 있고 try 블럭 또는 catch 블럭에 또 다른 try-catch 문이 포함될 수 있다. catch 블럭 내의 코드에서도 예외가 발생할 수 있기 때문이다. catch 블럭의 괄호 내에 선언된 변수는 catch 블럭 내에서만 유효하기 때문에 위의 모든 catch 블럭에 참조변수 e 하나 만을 사용해도 된다. 그러나 catch 블럭 내에 또 하나의 try-catch 문이 포함된 경우 같은 이름의 참조변수 e를 사용해서는 안 된다.
1.4 try-catch문에서의 흐름
try블럭 내에서 예외가 발생한 경우,
1) 발생한 예외와 일치하는 catch블럭이 있는지 확인한다
2) 일치하는 catch 블럭을 찾게 되면 그 catch 블럭 내의 문장들을 수행하고 전체 try-catch 문을 빠져나가서 그 다음 문장을 계속해서 수행한다. 만일 일치하는 catch 블럭을 찾지 못하면 예외는 처리되지 못한다.
try 블럭 내에서 예외가 발생하지 않은 경우,
1) catch 블럭을 거치지 않고 전체 try-catch문을 빠져나가서 수행을 계속한다.
1.5 예외의 발생과 catch 블럭
예외가 발생하게 되면 첫 번째 catch 블럭부터 차례로 내려가면서 catch 블럭의 괄호()내의 선언된 참조변수의 종류와 생성된 예외클래스의 인스턴스와 instanceof연산자를 이용해서 검사하게 되는데, 검사 결과가 true인 catch블럭을 만날 때까지 검사는 계속된다.
모든 예외 클래스는 Exception 클래스의 자손이므로, catch 블럭의 괄호()에 Exception클래스 타입의 참조변수를 선언해 놓으면 어떤 종류의 예외가 발생하더라도 이 catch 블럭에 의해서 처리된다.
printStackTrace()와 getMessage()
예외가 발생했을 때 생성되는 예외 클래스의 인스턴스에는 발생한 예외에 대한 정보가 담겨 있으며, getMessage()와 printStackTrace()를 통해서 이 정보들을 얻을 수 있다. catch 블럭의 괄호()에 선언된 참조변수를 통해 이 인스턴스에 접근할 수 있다.
- printStackTrace() : 예외발생 당시의 호출스택에 있었던 메서드의 정보와 예외 메시지를 화면에 출력한다.
- getMessage() : 발생한 예외클래스의 인스턴스에 저장된 메시지를 얻을 수 있다.
멀티 catch 블럭
JDK 1.7부터 여러 catch 블럭을 '|' 기호를 이용해서 하나의 catch 블럭으로 합칠 수 있게 되었고 이를 멀티 catch 블럭이라고 한다. 이를 통해 중복된 코드를 줄일 수 있다. 그리고 '|'로 연결할 수 있는 예외 클래스의 개수에는 제한이 없다. 단, 멀티 catch 블럭의 '|' 기호로 연결된 예외 클래스가 조상과 자손의 관계에 있다면 컴파일 에러가 발생한다. (이런 경우는 조상 클래스만 써주는 것과 동일하기 때문) 불필요한 코드는 제거하라는 의미에서의 에러이다. 또 하나의 catch 블럭으로 여러 예외를 처기하는 것이다 보니 발생한 예외를 멀티 catch 블럭으로 처리하게 되었을 때 어떤 예외가 발생한 것인지 알 수 없다. 따라서 다음의 경우는 사용할 수 없다.
try {
...
} catch (ExceptionA | ExceptionB e) {
e.methodA(); // 에러. ExceptionA에 선언된 methodA()는 호출 불가
if (e instanceof ExceptionA){
ExceptionA e1 = (ExceptionA) e;
e1.methodA(); // 가능.
} else { // if(e instanceof ExceptionB)
...
}
e.printStackTree();
}
필요한 경우 if와 instanceof를 이용해서 어떤 예외가 발생할 것인지 확인하고 개별적으로 처리할 수는 있다. 그러나 이런 경우 그냥 예외 블럭을 분리하면 되기 때문에 이렇게까지 해서 합칠 일은 거의 없다.
1.6 예외 발생시키기
키워드 throw를 이용해서 프로그래머가 고의로 예외를 발생시킬 수 있으며 방법은 아래의 순서를 따르면 된다.
1) 먼저 연산자 new를 이용해서 발생시키려는 예외 클래스의 객체를 만든다.
Exception e = new Exception("고의로 발생시켰음");
2) 키워드 throw를 이용해서 예외를 발생시킨다.
throw e;
RuntimeException 클래스와 그 자손에 해당하는 예외는 프로그래머에 의해 실수로 발생하는 것들이기 때문에 예외처리를 강제하지 않는다. 이렇게 컴파일러가 예외처리를 확인하지 않는 RuntimeException 클래스들은 'unchecked예외'라고 부르고, 예외처리를 확인하는 Exception클래스들은 'checked예외'라고 부른다.
1.7 메서드에 예외 선언하기
메서드의 선언부에 키워드 throws를 사용해서 메서드 내에서 발생할 수 있는 예외를 적어주면 메서드에 예외를 선언할 수 있다. 예외가 여러 개인 경우에는 쉼표로 구분한다.
void method() throws Exception {
// 메서드의 내용
}
만일 위와 같이 모든 예외의 최고조상인 Exception 클래스를 메서드에 선언하면 이 메서드는 모든 종류의 예외가 발생할 가능성이 있다는 뜻이다. 이렇게 예외를 선언하면, 이 예외뿐만 아니라 그 자손타입의 예외까지도 발생할 수 있다는 점에 주의해야 한다. 오버라이딩을 할 때는 단순히 선언된 예외의 개수가 아니라 상속관계까지 고려해야 한다.
선언부에 예외를 선언하면 메서드를 사용하려는 사람이 메서드의 선언부를 보았을 때, 이 메서드를 사용하기 위해서는 어떤 예외들이 처리되어져야 하는지 쉽게 알 수 있다. 즉, 어떤 상황에 어떤 종류의 예외가 발생할 가능성이 있는지 명시할 수 있고 이를 처리하도록 강요하기 때문에 코드가 더 견고해질 수 있다.
1.8 finally 블럭
finally 블럭은 예외 발생 여부에 상관없이 실행되어야할 코드를 포함시킬 목적으로 사용된다. try-catch 문의 끝에 선택적으로 덧붙여 사용할 수 있으며 try-catch-finally의 순서로 구성된다.
try {
// 예외가 발생할 가능성이 있는 문장들
} catch (Exception1 e1) {
// 예외처리를 위한 문장
} finally {
// 예외의 발생여부에 관계없이 항상 수행되어야 하는 문장들을 넣는다.
// finally 블럭은 try-catc문의 맨 마지막에 위치해야 한다.
}
예외가 발생한 경우는 try-> catch -> finally의 순, 발생하지 않은 경우에는 try -> finally의 순으로 실행된다.
try블럭에서 return문이 실행되는 경우에도 finally 블럭의 문장들이 먼저 실행된 후에 현재 실행 중인 메서드를 종료한다. catch블럭의 수행 중에 return 문을 만나도 finally 블럭의 문장들이 수행된다.
1.9 자동 자원 반환 - try-with-resources 문
JDK1.7부터 try-with-resources문이라는 try-catch문의 변형이 추가되었다. 이 구문은 입출력과 관련한 클래스를 사용할 때 유용하다. 입출력에 사용되는 클래스 중에서는 사용한 후에 꼭 닫아줘야 하는 것들이 있다. 그래야 사용했던 자원이 반환되기 때문이다.
try-with-resources 문의 괄호()안에 객체를 생성하는 문장을 넣으면 이 객체는 따로 close()를 호출하지 않아도 try 블럭을 벗어나는 순간 자동적으로 close()가 호출된다. 그 다음에 catch블럭 또는 finally 블럭이 수행된다.
// 괄호() 안에 두 문장 이상 넣을 경우 ;로 구분된다.
try (FileInputStream fis = new FileInputStream("score.dat");
DataInputStream dis = new DataInputStream(fis)) {
while(true){
score = dis.readInt();
System.out.println(score);
sum += score;
}
} catch (EOFException e) {
System.out.println("점수의 총합은 " + sum + "입니다.");
} catch (IOException e) {
ie.printStackTrace();
}
이처럼 try-with-resources문에 의해 자동으로 객체의 close()가 호출될 수 있으려면 클래스가 AutoCloseable이라는 인터페이스를 구현한 것이어야만 한다.
public interface AutoCloseable {
void close() throws Exception;
}
1.10 사용자정의 예외 만들기
기존 정의된 예외 클래스 외에 프로그래머가 새로운 예외 클래스를 정의하여 사용할 수 있다. 보통 Exception클래스 또는 RuntimeException 클래스로부터 상속받아 클래스를 만들지만, 필요에 따라서 알맞은 예외 클래스를 선택할 수 있다. 기존에는 주로 Exception을 상속받아서 'checked예외'로 작성하는 경우가 많았지만 요즘은 예외처리를 선택저긍로 할 수 있도록 RuntimeException을 상속받아서 작성하는 쪽으로 바뀌어가고 있다. checked예외는 반드시 예외처리를 해주어야 하기 때문에 예외처리가 불필요한 경우에도 try-cath문을 넣어서 코드가 복잡해지기 때문이다.
class MyException extends Exception{
//에러 코드 값을 저장하기 위한 필드 추가
private final int ERR_CODE; // 생성자를 통해 초기화 한다.
MyException (String msg, int ErrCode) { // 생성자
super(msg);
ERR_CODE = errCode;
}
MyException(String msg){
this(msg, 100); // ERR_CODE를 100(기본값)으로 초기화한다.
}
}
1.11 예외 되던지기 (exception re-throwing)
한 메서드에서 발생할 수 있는 예외가 여럿인 경우, 몇 개는 try-catch문을 통해서 메서드 내에서 자체적으로 처리하고 그 나머지는 선언부에 지정하여 호출한 메서드에서 처리함으로써 양쪽에서 나눠서 처리되도록 할 수 있다. 그리고 심지어는 단 하나의 예외에 대해서도 예외가 발생한 메서드와 호출한 메서드, 양쪽에서 처리하도록 할 수 있다.
이것은 예외를 처리한 후에 인위적으로 다시 발생시키는 방법을 통해서 가능한데, 이것을 '예외 되던지기'라고 한다.
먼저 예외가 발생할 가능성이 있는 메서드에서 try-catch문을 사용해서 예외를 처리해주고 catch문에서 필요한 작업을 행한 후에 throw 문을 사용해서 예외를 다시 발생시킨다. 다시 발생한 예외는 이 메서드를 호출한 메서드에게 전달되고 호출한 메서드의 try-catch문에서 예외를 또 다시 처리한다. 이 방법은 하나의 예외에 대해서 예외가 발생한 메서드와 이를 호출한 메서드 양쪽 모두에서 처리해줘야 할 작업이 있을 때 사용된다. 이 때 주의할 점은 예외가 발생한 메서드에서는 try-catch문을 이용해서 예외처리를 해줌과 동시에 메서드의 선언부에 발생할 예외를 throws에 지정해줘야 한다는 것이다.
반환값이 있는 return 문의 경우, catch 블럭에서도 return 문이 있어야 한다. 예외가 발생했을 경우에도 값을 반환해야 하기 때문이다. 또는 catch 블럭에서 예외 되던지기를 해서 호출한 메서드로 예외를 전달하면 return문이 없어도 된다. 그래서 검증에서도 assert문 대신 AssertError를 생성해서 던진다.
1.12 연결된 예외(chained exception)
한 예외가 다른 예외를 발생시킬 수도 있다. 예외A가 예외 B를 발생시켰다면 A를 B의 원인 예외라고 한다.
Throwable initCause (Throwable cause) // 지정한 예외를 원인 예외로 등록
Throwable getCause() //원인 예외를 반환
원인 예외로 등록해서 다시 예외를 발생시키는 이유는 여러가지 예외를 하나의 큰 분류의 예외로 묶어서 다루기 위해서이다. 또 다른 이유는 checked 예외를 unchecked예외로 바꿀 수 있도록 하기 위해서이다. checked예외로 예외처리를 강제한 이유는 프로그래밍 경험이 적은 사람도 보다 견고한 프로그램을 작성할 수 있도록 유도하기 위한 것이었는데 지금은 환경이 많이 달라졌다. 따라서 checked예외가 발생해도 예외를 처리할 수 없는 상황이 하나 둘 발생하기 시작했다. 이럴 때 의미없는 try-catch문을 추가하기보다 checked예외를 unchecked예외로 바꾸면 예외처리가 선택적이 되므로 억지로 예외처리를 하려고 하지 않아도 괜찮다.
'TIL > Java | Spring Boot' 카테고리의 다른 글
[Java] 스터디 5주차_컬렉션 프레임웍 (0) | 2022.05.22 |
---|---|
[Java] 스터디 4주차_java.lang 패키지와 날짜, 시간, 형식화 (0) | 2022.05.15 |
[Java] 스터디 2주차_객체지향프로그래밍2 (2) - 추상클래스, 인터페이스, 내부 클래스 (0) | 2022.05.01 |
[Java] 스터디 2주차_객체지향프로그래밍2 (1) - 상속, 오버라이딩, 제어자, 다형성 (0) | 2022.05.01 |
[Spring boot] Jenkins를 이용한 spring boot 자동 배포 CI (0) | 2022.04.29 |
댓글