예외 처리
프로그램 오류
프로그램이 실행 중 오작동을 하거나 비정상적으로 종료되는 경우가 있습니다. 이런한 결과를 초래하는 원인을 프로그램 에러 또는 오류라고 합니다. 이를 발생 시점에 따라 '컴파일 에러(compile-time error)'와 '런타임 에러(runtime error)'로 나눌 수 있는데, 글자 그대로 '컴파일 에러'는 컴파일 할 때 발생하는 에러고, 프로그램 실행 도중에 발생하는 에러를 '런타임 에러'라고 합니다.
이 외에도 '논리적 에러(logical error)'가 있는데, 컴파일도 잘되고 실행도 잘되지만 의도한 것과 다르게 동작하는 것을 말합니다. 예를 들어, 창고의 재고가 음수가 된다던가, 게임 프로그램에서 총알을 맞아도 죽지 않는 경우가 이에 해당합니다.
소스코드를 컴파일 하면 컴파일러가 소스 코드(*.java)에 대해 오타나 잘못된 구문 체크 등의 기본적인 검사를 수행하여 오류가 있는지를 알려줍니다. 컴파일러가 알려 준 에러들을 모두 수정해서 컴파일을 성공적으로 마치고 나면, 클래스 파일(*.class)이 생성되고, 생성된 클래스 파일을 실행할 수 있게 되는 것입니다.
하지만 컴파일을 에러 없이 성공적으로 마쳣어도 프로그램의 실행 시에 에러가 발행하지 않는 것은 아닙니다. 컴파일러가 실행 중에 발생할 수 있는 잠재적인 오류까지 완벽하게 검사할 수 없기 때문에 컴파일은 잘되었어도 실행 중에 에러에 의해서 잘못된 결과를 얻거나 프로그램이 비정상적으로 종료될 수 있습니다. 이러한 런타임 에러를 방지하려면 프로그램의 실행도중 발생할 수 있는 모든 경우를 고려하여 이에 대한 대비를 하는 것이 필요합니다.
자바에서는 실행 시(runtime) 발생할 수 있는 프로그램 오류를 '에러(error)'와 '예외(exception)', 두 가지로 구분하였습니다. 에러는 메모리 부족(OutOfMemoryError)이나 스택 오버플로우(StackOverflowError)와 같이 일단 발생하면 복구할 수 없는 심각한 오류이고, 예외는 발생하더라도 수습될 수 있는 비교적 덜 심각한 것입니다.
에러가 발생하면, 프로그램의 비정상적인 종료를 막을 길이 없지만, 예외는 발생하더라도 프로그래머가 이에 대한 적절한 코드를 미리 작성해 놓음으로써 프로그램의 비정상적인 종료를 막을 수 있습니다.
예외 클래스의 계층구조
자바에서는 실행 시 발생할 수 있는 오류(Exception과 Error)를 클래스로 정의하였습니다. 물론 Exception과 Error 역시 Object 클래스의 자손들입니다.

모든 예외의 최고 조상은 Exception 클래스이며, 상속계층도에서 볼 수 있듯이 예외 클래스들은 RuntimeException 클래스 및 그 자손들과, 나머지 Exception 클래스들로 나눌 수 있습니다.
RuntimeException 클래스들은 주로 프로그래머의 실수에 의해서 발생될 수 있는 예외들로 자바의 프로그래밍 요소들과 관계가 깊습니다. 예를 들면, 배열의 범위를 벗어나거나(ArrayIndexOutOfBoundsException), 값이 null인 참조변수의 멤버를 호출하거나(NullPointerException), 클래스간의 형변환을 잘못하던가(ClassCastException), 정수를 0으로 나누려고(ArithmeticException)하는 경우에 발생합니다.
나머지 Exception 클래스들은 주로 외부의 영향으로 발생하는 것들로서, 프로그램의 사용자들의 동작에 의해서 발생하는 경우가 많습니다. 예를 들면, 존재하지 않는 파일의 이름을 입력하던가(FileNotFoundException), 실수로 클래스의 이름을 잘못 적던가(ClassNotFoundException), 또는 입력한 데이터 형식이 잘못된(DataFormatException) 경우에 발생합니다.
예외 처리하기: try-catch문
프로그램의 실행 중에 발생하는 에러는 어쩔 수 없지만, 예외는 프로그래머가 이에 대한 처리를 미리 해야합니다. 예외 처리(exception handling)란, 프로그램 실행 시 발생할 수 있는 예기치 못한 예외에 대비한 코드를 작성하는 것이며, 예외처리의 목적은 예외의 발생으로 인한 실행 중인 프로그램의 갑작스런 비정상 종료를 막고, 정상적인 실행상태를 유지하는 것입니다.
발생한 예외를 처리하지 못하면, 프로그램은 비정상적으로 종료되며, 처리되지 못한 에외(uncaught exception)는 JVM의 '예외 처리기(UncaughtExceptionHandler)'가 받아서 예외의 원인을 화면에 출력합니다.
예외를 처리하기 위해서는 try-catch문을 사용하며, 그 구조는 다음과 같습니다.
try {
// 예외가 발생할 가능성이 있는 문장들
} catch (Exception1 e1){
// Exception1 발생 시 처리 문장
} catch (Exception2 e2) {
// Exception2 발생 시 처리 문장
} catch (Exception3 e3) {
// Exception3 발생 시 처리 문장
}
try블럭에는 실행할 문장들을 넣고, try블럭에서 예외가 발생하면 catch블럭 중에서 발생한 예외의 종류와 일치하는 단 하나의 catch블럭만 수행됩니다. 발생한 예외의 종류와 일치하는 catch블럭이 없으면 예외는 처리되지 않습니다. 예외가 발생하면 예외 객체가 생성되는데, 이 객체의 예외의 정보가 있고 catch블럭에 선언된 참조 변수로 접근할 수 있습니다.
if문과 달리, try블럭이나 catch블럭 내에 문장이 하나뿐이어도 중괄호{ }를 생략할 수 없습니다.
try-catch문에서의 흐름
try-catch문에서, 예외가 발생한 경우와 발생하지 않았을 때의 실행 흐름이 달라지는데, 실행 순서는 다음과 같습니다.
> try블럭 내에서 예외가 발생한 경우
- 발생한 예외와 일치하는 catch블럭이 있는지 찾습니다.
- 일치하는 catch블럭을 찾게 되면, 그 catch블럭 내의 문장들을 수행하고 전체 try-catch문을 빠져나가서 수행을 계속합니다.
만약, 일치하는 catch블럭이 없으면, 예외는 처리되지 않습니다.
try블럭에서 예외가 발생하면, 예외가 발생한 위치 이후에 있는 try블럭의 문장들은 수행되지 않습니다.
> try블럭 내에서 예외가 발생하지 않는 경우
- catch블럭을 건너뛰고 전체 try-catch문을 빠져나가서 수행을 계속합니다.
예외의 발생과 catch블럭
catch블럭은 괄호( )와 블럭{ }으로 나눠져 있는데, 괄호( )에는 처리하려는 예외와 같은 타입의 참조 변수를 선언하고 블럭{ }에는 예외가 발생했을 때 실행될 문장들을 넣습니다.
예외가 발생하면, 발생한 예외에 해당하는 클래스의 인스턴스가 만들어지는데, 이 인스턴스에는 발생한 예외에 대한 정보가 담겨있으며, 괄호( )안의 참조 변수로 발생한 예외의 정보를 얻을 수 있습니다.
try블럭 내에서 예외가 발생하면, 첫 번째 catch블럭부터 차례로 내려가면서 catch블럭의 괄호( )내에 선언된 참조 변수의 타입과 생성된 예외 인스턴스를 instancefo 연산자로 검사합니다. 검사 결과가 true인 catch블럭을 찾으면 블럭에 있는 문장들을 수행한 후에 try-catch문을 빠져나가고 예외는 처리됩니다. 그러나 검사결과가 true인 catch블럭이 하나도 없으면 예외는 처리되지 않습니다.
모든 예외 클래스는 Exception의 자손이므로, catch블럭의 괄호( )에 Exception타입의 참조 변수를 선언하면 어떤 종류의 예외가 발생해도 이 catch블럭에 의해 처리됩니다.
printStackTrace()와 getMessage()
예외가 발생했을 때 생성되는 예외 인스턴스에는 발생한 예외에 대한 정보가 담겨 있으며, catch블럭의 괄호( )에 선언된 참조 변수를 통해서 예외 인스턴스에 접근할 수 있습니다. 이 참조 변수는 선언된 catch블럭 내에서만 사용 가능하며, 다음 2가지 메서드가 자주 사용됩니다.
- printStackTrace(): 예외 발생 당시의 호출 스택(Call Stack)에 있었던 메서드의 정보와 예외 메시지를 화면에 출력
- getMessage(): 발생한 예외 클래스의 인스턴스에 저장된 메시지를 반환
try {
...
} catch (Exception e) {
e.printStackTrace();
System.out.println("예외메시지: " + e.getMessage());
}
멀티 catch블럭
JDK 7부터 여러 catch블럭을 '|' 기호를 이용해서, 하나의 catch블럭으로 합칠 수 있게 되었으며, 이를 '멀티 catch블럭'이라 합니다.
try {
...
} catch (ExceptionA | ExceptionB e) {
e.printStackTrace();
}
위 코드에서 알 수 있듯이 '멀티 catch블럭'을 사용하면 중복된 코드를 줄일 수 있으며, 이때 '|' 기호로 연결할 수 있는 예외 클래스의 개수에는 제한이 없습니다.
try {
} catch (ExceptionA | ExceptionB e) {
e.methodA(); // error
if(e instanceOf ExceptionA) {
ExceptionA ea = (ExceptionA)e;
ea.methodA();
}
}
그리고 멀티 catch는 하나의 catch블럭으로 여러 예외를 처리하는 것이기 때문에, 발생한 예외를 멀티 catch블럭으로 처리하게 되었을 때, 멀티 catch블럭 내에서는 실제로 어떤 예외가 발생한 것인지 알 수 없습니다. 그래서 참조변수 e로 멀티 catch블럭에 선언된 예외 클래스들의 공통 분모인 조상 예외 클래스에 선언된 멤버만 사용할 수 있습니다.
필요하다면 위와 같이 instanceof로 예외를 확인 후 개별적으로 처리가 가능하나, 굳이 이렇게까지 하면서 catch블럭을 합칠 일은 없을 것입니다.
예외 발생시키기
다음과 같이 예외 클래스의 객체를 생성해 키워드 throw를 사용하면 프로그래머가 고의로 예외를 발생시킬 수 있습니다.
try {
throw new Exception("고의 에러");
} catch (Exception e) {
e.printStackTrace();
}
Exception 인스턴스를 생성할 때, 생성자에 문자열을 넣어 주면, 이 문자열이 Exception 인스턴스에 메시지로 저장됩니다. 이 메시지는 getMesage()를 이용해 얻을 수 있습니다.
public static void main(String[] args) {
throw new Exception();
}
위 코드는 컴파일 시 에러가 발생하면서 컴파일에 실패합니다. 예외 처리가 필요한 부분에 예외 처리가 되어 있지 않다는 뜻입니다.
이렇게 컴파일러가 예외 처리를 확인하는 Exception 클래스들을 'checked Exception' 이라고 합니다.
public static void main(Stirng[] args) {
throw new RuntimeException();
}
반면 위 코드는 예외를 처리하지 않았음에도 불구하고 앞의 예제와는 달리 성공적으로 컴파일이 됩니다. 그러나 실행하면, RuntimeException이 발생하여 비정상적으로 종료됩니다. 이렇게 컴파일러가 예외 처리를 강제하지 않는 RuntimeException 클래스들을 'unchecked Exception'이라고 합니다.
메서드에 예외 선언하기
예외를 메서드에 선언하는 것은 실제로 예외를 처리하는 것이 아니라, 이 메서드를 호출하면 이런 예외가 발생할 수 있으니 이 메서드를 호출하는 쪽에서 예외를 처리해야 한다고 알려주는 것입니다. 즉, 예외 처리를 호출한 쪽으로 떠넘기는 것입니다.
메서드에 예외를 선언하는 것은 메서드의 선언부에 키워드 throws를 사용해서 메서드 내에서 발생할 수 있는 예외를 적어주면 됩니다.
void method() throws Exception1, Exception2, ... {
// 메서드 내용
}
만일 모든 예외의 최고 조상인 Exception클래스를 메서드에 선언하면, 이 메서드에서 모든 종류의 예외가 발생할 수 있다는 의미입니다. 예외를 선언하면, 선언된 예외뿐만아니라 그 예외의 자손 예외까지도 발생할 수 있다는 뜻이기 때문입니다. 그렇기 때문에 메서드를 오버라이딩 할 때는 단순히 선언된 예외의 개수가 아니라 상속관계까지 고려해야 합니다.
자바 이전의 프로그래밍 언어들은 대부분 메서드에 예외를 선언하지 않기 때문에, 경험 많은 프로그래머가 아니고서는 어떤 상황에 어떤 종류의 예외가 발생할 가능성이 있는지 모두 예상하기 힘들기 때문에 그에 대한 대비를 하는 것이 어려웠습니다. 그러나 자바에서는 메서드를 작성할 때 메서드 내에서 발생할 가능성이 있는 예외를 메서드의 선언부에 명시하여 이 메서드를 사용하는 쪽에서 이에 대한 처리를 하도록 가요하기 때문에, 프로그래머들의 짐을 덜어 주는 것은 물론이고 보다 견고한 프로그램 코드를 작성할 수 있도록 도와줍니다.
RuntimeException클래스들을 메서드 선언부의 throws에 선언한다고 문제가 되지는 않지만, 보통 반드시 처리해주어야 하는 필수 예외(checkedException)만 선언합니다.
사실 예외를 메서드의 throws에 명시하는 것은 예외를 처리하는 것이 아니라, 자신을 호출한 메서드에게 예외를 전달하여 예외 처리를 떠 맡기는 것입니다. 예외를 전달받은 메서드가 다시 자신을 호출한 메서드에게 전달할 수 있으며, 이런식으로 계속 호출스택에 있는 메서드들을 따라 전달되다가 제일 마지막에 있는 main메서드에서도 예외가 처리되지 않으면, main메서드마저 종료되어 프로그램 전체가 종료됩니다. 그렇기 때문에 반드시 어느 한 곳에서는 try-catch문으로 예외를 처리해주어야 합니다.
예외가 발생한 메서드 내에서 자체적으로 처리해도 되는 것은 메서드 내에서 try-catch문을 사용해서 처리하고, 메서드 내부에서 복구가 불가능한 문제는 예외를 메서드에 선언해서, 호출한 메서드에서 처리해야 합니다.
finally블럭
finally블럭은 예외의 발생여부에 상관없이 실행되어야하는 코드를 포함시킬 목적으로 사용됩니다. try-catch문의 끝에 선택적으로 덧붙여 사용할 수 있으며, try-catch-finally의 순서로 구성됩니다.
try {
} catch (Exception e) {
} finally {
// 예외의 발생 여부에 관계없이 항상 수행되어야 하는 문장
}
예외가 발생한 경우에는 'try -> catch -> finally' 순으로 실행되고, 예외가 발생하지 않은 경우에는 'try -> finally'의 순으로 실행됩니다.
finally블럭은 try블럭이나 catch블럭에서 명시적으로 return을 수행해도 실행됩니다.
자원 자동 반환: try-with-resources문
JDK 7부터 try-with-resources문이라는 try-catch문의 변형이 새로 추가되었습니다. 입출력(I/O)에 사용되는 클래스 중에는 사용한 후에 꼭 닫아줘야하는 것들이 있는데, 이 구문은 그런 클래스를 사용할 때 유용합니다. 그래야 사용했던 자원(resources)이 반환되기 때문입니다.
try {
fis = new FileInputStream("score.dat");
dis = new DataInputStream(fis);
} catch (IOException e) {
e.printStackTrace();
} finally {
dis.close();
}
위의 코드는 DataInputStream을 사용해서 파일로부터 데이터를 읽는 코드인데, 데이터를 읽는 도중에 예외가 발생하더라도 DataInputStream이 닫히도록 finally블럭 안에 close()를 넣었습니다.
그러나 close()가 예외를 발생시킬 수도 있기 때문에 아래와 같이 해야 올바른 처리가 됩니다.
try {
fis = new FileInputStream("score.dat");
dis = new DataInputStream(fis);
...
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
dis.close();
} catch (IOException ie) {
ie.printStackTrace();
}
}
finally블럭 안에 try-catch문을 추가해서 close()에서 발생할 수 있는 예외를 처리하도록 변경했는데, 코드가 복잡해져서 별로 보기에 좋지 않습니다. 더 나쁜 것은 try블럭에서 예외가 발생한 후 finally블럭에서 또 예외가 발생하면, try블럭의 예외는 무시된다는 것입니다.
이런한 점을 개선하기 위해서 try-with-resources문이 추가된 것입니다. 위의 코드를 try-with-resources문으로 바꾸면 다음과 같습니다.
try (FileInputStream fis = new FileInputStream("score.dat");
DataInputStream dis = new DataInputStream(fis);) {
while (true) {
score = dis.readInt();
sum += score;
}
} catch (EOFException e) {
System.out.println("총합 : " + sum);
} catch (IOExceptino ie) {
ie.printStackTrace();
}
try-with-resources문의 괄호( )안에 객체를 생성하는 문장을 넣으면, 이 객체는 따로 close()를 호출하지 않아도 try블럭을 벗어나는 순간 자동적으로 close()가 호출됩니다.
이처럼 try-with-resources문에 의해 자동으로 객체의 close()가 호출되려면, 클래스가 AutoCloseable이라는 인터페이스를 구현한 것이어야 합니다.
public interface AutoCloseable {
void close() throws Exception;
}
try-with-resources에 의해 자동 호출된 close()에서 예외가 발생하게 되면, try블럭에서 예외가 발생했더라도 예외가 출력됩니다. try블럭에서 발생한 예외가 '주된 예외(primary exception)', 자동 호출된 close()에서 발생한 예외가 '억제된 예외(suppressed exception)'라고 출력됩니다.
public class Throwable {
public final synchronized void addSuppressed(Throwable exception) { ... }
public final synchronized Throwable[] getSuppressed() { ... }
}
suppressed 예외는 모든 예외(Exception, Error)의 최상위 부모 클래스인 Throwable에서 제공하는 기능으로 자바의 모든 예외 객체는 suppressed 예외를 추가하거나 조회할 수 있습니다.
사용자 정의 예외
기존의 정의된 예외 클래스 외에 프로그래머가 새로운 예외 클래스를 직접 정의하여 사용할 수도 있습니다. 보통 Exception클래스 또는 RuntimeException클래스로부터 상속받아 클래스를 만들지만, 필요에 따라서 알맞은 예외 클래스를 선택해도 됩니다.
class MyException extends Exception {
MyException(String msg) {
super(msg);
}
}
Exception클래스는 생성 시에 String값을 받아서 메시지로 저장할 수 있기 때문에, 위와 같이 String을 매개변수로 받는 생성자를 추가해주어야 합니다.
다음은 메시지뿐만 아니라 에러코드 값도 저장할 수 있도록 개선한 예외 클래스입니다.
class MyException extends Exception {
private final int ERR_CODE;
MyException(String msg, int errCode) {
super(msg);
ERR_CODE = errCode;
}
MyException(String msg) {
this(mgs, 100);
}
public int getErrCode() {
return ERR_CODE;
}
}
기존의 예외 클래스는 주로 Exception을 상속받아서 'checked 예외'로 작성한는 경우가 많았지만, 요즘은 가능하면 예외처리를 선택적으로 할 수 있도록 RuntimeException을 상속받아서 작성하기도 합니다.
예외 되던지기
한 메서드에서 발생할 수 있는 예외가 여럿인 경우, 몇 개는 try-catch문을 통해서 메서드 내에서 자체적으로 처리하고, 그 나머지는 선언부에 지정하여 호출한 메서에서 처리하도록 함으로써, 양쪽에서 나눠서 처리되도록 할 수 있습니다. 그리고 심지어 단 하나의 예외에 대해서도 예외가 발생한 메서드와 호출한 메서드, 양쪽에서 처리하도록 할 수 있습니다.
이것은 예외를 처리한 후에 인위적으로 다시 발생시키는 방법을 통해서 가능한테, 이것을 '예외 되던지기(exception re-throwing)'라고 합니다. 먼저 예외가 발생할 가능성이 있는 메서드에서 try-catch문을 사용해서 예외를 처리해주고 catch문에서 필요한 작업을 행한 후에 throw문을 사용해서 예외를 다시 발생시킵니다. 다시 발생한 예외는 이 메서드를 호출한 메서드에게 전달되고 호출한 메서드의 try-catch문에서 예외를 또다시 처리합니다.
public static void main(String[] args) {
try {
method1();
} catch (Exception e) {
System.out.println("main에서 처리");
}
}
static void method1() throws Exception {
try {
throw new Exception();
} catch (Exception e) {
System.out.println("method1에서 처리");
throw e;
}
}
이 방법은 하나의 예외에 대해서 예외가 발생한 메서드와 이를 호출한 메서드 양쪽 모두에서 처리해줘야 할 작업이 있을 때 사용됩니다. 이 때 주의할 점은 예외가 발생할 메서드에서는 try-catch문을 사용해서 예외처리를 해줌과 동시에 메서드의 선언부에 발생할 예외를 throws에 지정해줘야 한다는 것입니다.
연결된 예외(chained exception)
한 예외가 다른 예외를 발생시킬 수도 있습니다. 예를 들어 예외 A가 예외 B를 발생시켰다면, A를 B의 '원인 예외(cause exception)'라고 합니다.
try {
throw new SpaceException();
} catch (SpaceException se) {
InstallException ie = new InstallException("설치중 에외");
ie.initCause(se);
throw ie;
} catch (MemoryException me) {
...
}
위 코드에서는 SpaceException이 발생했을 때 catch블럭에서 InstallException을 생성한 후에, initCause()로 SpaceException을 InstallException의 원인 예외로 등록합니다.
public class Throwable {
public synchronized Throwable initCause(Throwable cause) { ... }
public synchronized Throwable getCause() { ... }
}
initCause()는 모든 예외(Exception, Error)의 최상위 부모 클래스인 Throwable에서 제공하는 기능으로 자바의 모든 예외에서 사용가능합니다.
이렇게 발생한 예외를 원인 예외로 등록해서 다시 예외를 발생시키는 이유는 다음 두 가지 이유가 있습니다.
1. 여러가지 예외를 하나의 큰 분류의 예외로 묶어서 다루기 위해서
try {
throw new SpaceException();
} catch (InstallException e) {
e.printStackTrace();
}
만약 위와 같이 InstallException을 SpaceException과 MemoryException의 공통 예외 클래스로 사용하면, catch블럭에서 실제로 발생한 예외가 어떤 것인질 알 수 없다는 문제가 생깁니다. 또한 SpaceException과 MemoryException이 Exception이 아닌 InstallException을 상속하도록 변경해야 하는 것도 부담입니다.
2. checked 예외를 unchecked 예외로 바꾸기 위해서
static void startInstall() {
if(!enoughSpace())
throw new RuntimeException(new SpaceException("설치 공간 부족"));
}
checked 예외로 예외처리를 강제한 이유는 프로그래밍 경험이 적은 사람도 보다 견고한 프로그램을 작성할 수 있도록 유도하기 위한 것이었는데, 지금은 자바가 처음 개발되던 1990년대와 컴퓨터 환경이 많이 달라져, checked 예외가 발생해도 예외를 처리할 수 없는 상황이 하나둘 발생하기 시작했습니다. 이럴 때 할 수 있는 일이라고는 그저 의미없는 try-catch문을 추가하는 것뿐인데, checked 예외를 unchecked 예외로 바꾸면 예외처리가 선택적이 되므로 억지로 예외처리를 하지 않아도 됩니다.
Exception클래스와 RuntimeException클래스는 에러 메시지를 매개변수로 받는 생성자 외에 원인 예외(cause exception)을 매개변수로 받는 생성자도 제공하고 있습니다.
'Lang > Java' 카테고리의 다른 글
| [Java 21] (10) - date, time and formatting (0) | 2025.10.31 |
|---|---|
| [Java 21] (9) - java.lang package & util classes (0) | 2025.10.24 |
| [Java 21] (7) - Object-oriented Programming 2 (0) | 2025.10.03 |
| [Java 21] (6) - Object-oriented Programming 1 (0) | 2025.09.29 |
| [Java 21] (5) - array (1) | 2025.09.25 |