티스토리 뷰
자바에서 예외 처리 방법 (try, catch, throw, throws, finally)
try - catch - finally
자바 내에서는 Exception을 처리하기 위해서 흔히 말하는 try - catch - finally구문을 활용한다.
말그대로 실행, 에러잡기, 최종 결과라는 뜻인데 다음 예제 코드를 보자.
try {
실행 코드
} catch (NullPointerException e1) {
e1 발생 시 실행되는 코드
} catch (ClassCastException e2 || IllegalArgumentException e3) {
e2 혹은 e3 발생 시 실행되는 코드
} catch (RunTimeException e4) {
e4 발생 시 실행되는 코드
} ...
finally {
실행코드의 끝 혹은 catch종료 후 모든 try catch구문이 완료되고 실행되는 코드
}
1. try
가장 먼저 실행되는 코드로 실제로 예외가 발생할 것 같은 로직을 핸들링하기 위한 블록이다. I/O 혹은 다양한 connection과 관련된 연결을 하고 로직을 수행하는데 많이 사용된다.
2. catch
try 블록 내부에서 발생하는 exception이 있을 때 동일한 class의 exception이 발생했을 때 잡아서 동작하는 구문이다.
각각 다른 exception을 연달아서 catch 하도록 할 수 있으며 만약 가장 아래에 상위 exception이 있다면 위에서 catch된 exception들을 제외하고 나머지 exception에 대한 예외를 catch한다.
3. finally
try - catch 문이 발생하였을 때 try가 끝나건 catch가 되건 무조건 실행되는 블록이다.
throw
강제로 어떠한 Exception을 개발자가 발생 시킬 수 있도록 하는 구문이다. 흔히 말하는 Unchecked Exception(ex NullPointerException, IllegalArgumentException)들만 강제로 실행 시킬 수 있으며 Checked Exception은 강제로 해당 키워드로 발생시킬 수 없다.
public void throwException {
throw new RuntimeException();
}
try {
throw new RuntimeException();
} catch (RuntimeException e) {
...
}
throws
throws는 메소드 단에서 사용가능하며 해당 메소드 내에서 exception이 발생한다면 이를 선언한 상위 클라이언트에서 exception이 전달 된다.
즉, throws로 선언된 메소드를 호출한 메소드에서 exception을 처리할 수 있도록 보완시켜주는 것이다.
throws를 선언한 메소드를 호출할 때는 결국 그 메소드에서도 exception이 발생한다는 뜻으로 해당 메소드에도 throws를 선언하지 않으면 컴파일 에러가 발생한다.
public static void main(String[] args) {
testException(); // 컴파일 에러
}
private void testException() throws Exception {
throws new RuntimeException();
}
따라서 IDE가 추천하는 대로 컴파일에러에 처리를 호출하는 메소드 또한 throws를 선언하거나, try 구문으로 감싸 exception에 대한 처리를 진행해주어야 한다.
Exception과 Error의 차이는?
예외 처리에는 크게 따졌을 때는 Exception과 Error가 있다.
이게 뭐다하고 딱 구분짓는 건 개발과정에서 어떠한 문제가 발생했을 때 그 문제의 원인이 하드웨어에 있냐, 개발자가 개발한 코드에 있냐 이다.
Error의 가장 대표적인 예는 OutOfMemoryError로 흔히 아는 OOM이다. 물론 OOM이 개발자가 과도하게 메모리를 소모해서 발생했다라고 할 수는 있지만, 결국에는 하드웨어적인 한계때문에 발생하는 문제여서 이는 Error에 분류된다.
(C#에서는 이를 Exception으로 분류하기는 하는데 참고만 해두자.)
Error
- 하드웨어 내의 문제로 인해 프로그램에 이상이 생겼을 경우 발생
- 자바 프로그램 외의 문제에 해당
OutOfMemoryError,StackOverflowError...
Exception
- 개발자의 잘못된 코딩에 의한 코드로 발생하는 문제
- Exception handling을 통해 프로세스 자체에 영향이 가는 것을막을 수 있음
자바가 제공하는 예외 계층 구조
항상 모든 클래스의 상위 클래스는 Object이므로 이는 넘어가고 Exception과 Error는 상위클래스로 Throwable을 가진다.
Throwable은 전체적인 Exception과 Error가 모두 사용할 수 있는 편의 메소드들을 제공한다.
printStackTrace()- 첫줄에 예외 메시지를 출력하고 다음줄 부터 예외가 발생한 클래스들의 관계 즉, stack trace를 출력한다.
getMessage()- 예외 메시지를 String 형태로 받는다.
이때, Exception과 Error는 위와 같이 두가지 형태로 나뉘어진다.
Checked Exception
반드시 명시적으로 처리해야하는 Exception에 대해서 표현하기 위해서 나온 Exception이다.
따라서, 위에서 throws를 처리한 것 처럼, 이를 처리하기 위해서는 메소드단에 throws를 처리하거나, try-catch를 통해서 예외를 처리해주어야 한다.
- Rollback 불가
IOException,SQLException...
Unchecked Exception
Checked Exception을 제외한 Runtime Exception, Error가 이에 속하며 예외에 대한 처리를 굳이하지 않아도 된다. Check Exception처럼 throws나 try-catch로 잡을 필요가 없다.
- Rollback 진행
결국 이 둘의 차이는 컴파일 시점에서 확인을 해야하느냐 하지 않아도되느냐의 차이이다. Checked Exception은 컴파일 시점에서 이를 감지하기 때문에 미리 처리를 해줄 수 있는 반면 Unchecked Exception은 실행시점에서밖에 알 수 없다.
커스텀한 예외 만드는 방법
주로 Exception 혹은 RuntimeException을 상속받아 작성한다. 이 둘의 차이는 결국 checked Exception을 만드느냐, unchecked Exception을 만드느냐에 따라서 갈린다.
조금 더 구체적인 Exception의 네이밍과 에러 메시지를 반환하기 위해서 작성하기 위함이다.
public class CustomException extends RuntimeException {
public CustomException(String message) {
super(message);
}
}
super메소드는 상속에서 이야기했다시피 부모 클래스의 생성자를 불러오는 메소드이다. 즉, RuntimeException의 메소드 자체를 상속받아서 printStackTrace()나 getMessage()같은 메소드들을 가져다가 쓸 수 있는 것이다.
대부분의 커스텀 예외는 Exception과 RuntimeException을 상속받아서 구현한다. Error의 경우, 하드웨어적인 문제로 인한 Error만 존재해야하기 때문에 굳이 개발자가 건들면 좋을 것이 없다고 생각한다.
실행과정에서 발생하는 대부분의 커스텀 Exception은 RuntimeException을 상속받아서 사용한다. 이렇게 되면 이 커스텀 Exception을 던지는 메소드를 사용하는데 있어서 throws 를 강제로 사용하지 않아도 되기 때문이다.
- Total
- Today
- Yesterday