1. 예외처리
1.1 프로그램 오류
프로그램이 실행 중에 어떤 원인에 의해서 오작동을 하거나 비정상적으로 종료되는 경우가 있다.
이러한 결과를 초래하는 원인을 프로그램 에러 또는 오류라고 한다.
이를 발생시점에 따라서 '컴파일 에러'와 '런타임 에러'로 나눌 수 있고,
이 외에도 '논리적 에러'가 있다.
컴파일러 에러 : 컴파일 할 때 발생하는 에러
런타임 에러 : 프로그램 실행 도중에 발생하는 에러
논리적 에러 : 컴파일도 잘 되고 실행도 잘 되지만 의도와 다르게 동작하는 것
소스코드를 컴파일 하면 컴파일러가 소스코드(*.java)에 대해서
오타나 잘못된 구문, 자료형 체크 등의 기본적인 검사를 수행해서 오류가 있는지 알려 준다.
컴파일러가 알려 준 에러들을 모두 수정해서 컴파일을 성공적으로 마치고 나면
클래스 파일(*.class)이 생성되고, 생성된 클래스 파일을 실행할 수 있게 된다.
하지만 컴파일을 에러없이 성공적으로 마쳤다고 해서 프로그램의 실행 시에도 에러가 없는 것은 아니다.
컴파일러가 소스코드의 기본적인 사항은 컴파일 시에 모두 걸러 줄 수는 있지만,
실행도중에 발생할 수 있는 잠재적인 오류까지 검사할 수 없기 때문에
컴파일은 잘 되었어도 실행 중에 에러에 의해서
잘못된 결과를 얻거나 프로그램이 비정상적으로 종료될 수 있다.
런타임 에러를 방지하기 위해서는 프로그램의 실행도중
발생할 수 있는 모든 경우의 수를 고려해서 대비하는 것이 필요하다.
자바에서는 실행 시(runtime)발생할 수 있는 프로그램 오류를
'에러(eroor)'와 '예외(exception)', 두 가지로 구분했다.
에러는 메모리 부족(OutOfMemoryError)나 스택오버플로우(StackOverflowerError)와 같이
일단 발생하면 복구할 수 없는 심각한 오류이고, 예외는 발생하더라도 수습될 수 있는 비교적 덜 심각한 것이다.
에러가 발생하면, 프로그램의 비정상적인 종료를 막을 길이 없지만,
예외는 발생하더라도 프로그래머가 이에 대한 적절한 코드를 미리 작성해 놓음으로써
프로그램의 비정상적인 종료를 막을 수 있다.
에러(error) 프로그램 코드에 의해서 수습될 수 없는 심각한 오류
예외(exception) 프로그램 코드에 의해서 수습될 수 있는 다소 미약한 오류
1.2 예외 클래스의 계층구조
자바에서는 실행 시 발생할 수 있는 오류(Exception과 Error)를 클래스로 정의했다.
모든 클래스의 조상은 Object클래스이므로 Exception과 Error클래스 역시 Object클래스의 자손들이다.
앞으로 RuntimeException클래스와 그 자손 클래스들을 'RuntimeException클래스들'이라 하고,
1.3 예외처리하기 - try - catch문
프로그램 실행도중에 발생하는 에러는 어쩔 수 없지만, 예외는 프로그래머가 이에 대한 처리를 미리 해줘야 한다.
예외처리(exception handling)란, 프로그램 실행 시 발생할 수 있는 예기치 못한 예외의 발생으로 인한 실행 중인
프로그램의 갑작스런 비정상 종료를 막고, 정상적인 실행상태를 유지할 수도 있도록 하는 것이다.
예외처리(exception handling)의
정의 - 프로그램 실행 시 발생할 수 있는 예외에 대비한 코드를 작성하는 것
목적 - 프로그램의 비정상 종료를 막고, 정상적인 실행상태를 유지하는 것
! 에러와 예외는 모두 실행 시(runtime) 발생하는 오류
발생한 예외를 처리하지 못하면, 프로그램은 비정상적으로 종료되며, 처리되지 못한 예외(uncaught exception)는
JVM의 '예외처리기(UncaughtExceptionHandler)'가 받아서 예외의 원인을 화면에 출력한다.
예외를 처리하기 위해서는 try-catch문을 사용하며, 그 구조는 다음과 같다.
try{
//예외가 발생할 가능성이 있는 문장들을 넣는다.
} catch (Exception1 e1) {
// Exception1이 발생했을 경우, 이를 처리하기 위한 문장을 적는다.
} catch (Exception2 e2) {
// Exception2이 발생했을 경우, 이를 처리하기 위한 문장을 적는다.
} catch (ExceptioN eN) {
// ExceptionN이 발생했을 경우, 이를 처리하기 위한 문장을 적는다.
}하나의 try블럭 다음에는 여러 종류의 예외를 처리할 수 있도록 하나 이상의 catch블럭이 올 수 있으며,
이 중 발생한 예외의 종류와 일치하는 단 한 개의 catch블럭만 수행된다.
발생한 예외의 종류와 일치하는 catch블럭이 없으면 예외는 처리되지 않는다.
! if문과 달리, try블럭이나 catch블럭 내에 포함된 문장이 하나뿐이어도 괄호{}를 생략할 수 없다.
class ExceptionEx1 {
public static void main(String[] args) {
try {
try { } catch (Exception e) { }
} catch (Exeption e) {
try { } catch (Exception e) { } // 에러, 변수 e가 중복 선언됐다.
} // try-catch의 끝
try {
} catch (Exception e) {
} // try-catch의 끝
} // main 메서드의 끝
}위 코드는 아무 일도 하지 않는다.
단순히 try-catch문의 사용 예를 보여 주기 위해서 작성한 코드다.
이처럼 하나의 메서드 내에 여러 개의 try-catch문이 사용될 수 있으며,
try블럭 또는 catch블럭에 또 다른 try-catch문이 포함될 수 있다.
catch블럭 내의 코드에서도 예외가 발생할 수 있기 때문이다.
catch블럭의 괄호 내에 선언된 변수는 catch블럭 내에서만 유효하기 때문에,
위 모든 catch블럭에 참조변수 'e' 하나만 사용한다.
그러나 catch블럭 내에 또 하나의 try-catch문이 포함된 경우,
같은 이름의 참조변수를 사용해서는 안 된다.
각 catch 블럭에 선언된 두 참조변수의 영역이 서로 겹치므로 다른 이름을 사용해야만 서로 구별되기 때문이다.
따라서 위 예제에서 catch블럭 내 try-catch문에 선언되어 있는 참조변수의 이름을 'e'가 아닌 다른 것으로 바꿔야 한다.
class ExceptionEx2 {
public static void main(String args[]) {
int number = 100;
int result = 0;
for(int i=0; i<10; i++) {
result = number / (int) (Math.random()*10); // 7번째 라인
System.out.println(result);
}
} // main 끝
}결과 : 20 / 100 /
java.lang.ArithmeticException / by zero
at ExceptionEx2.main(ExceptionEx2.java:7) <- ExceptionEx2.java의 7번째 라인
1.4 try-catch문에서의 흐름
try-catch문에서 예외가 발생한 경우와 발생하지 않았을 때의 흐름(문장의 실행순서)이 달라지는데,
- try블랙 내에서 예외가 발생한 경우,
- 발생한 예외와 일치하는 catch 블럭이 있는지 확인한다.
- 일치하는 catch블럭을 찾게 되면, 그 catch 블럭 내의 문장들을 수행하고
try - catch문을 빠져나가서 그 다음 문장을 계속해서 수행한다.
만일 일치하는 catch블럭을 찾지 못하면, 예외는 처리되지 못한다.
- try블럭 내에서 예외가 발생하지 않은 경우,
- catch블럭을 거치고 않고 전체 try-catch문을 빠져나가서 수행을 계속한다.
class ExceptionEx4 {
public static void main(String args[]) {
System.out.println(1);
System.out.println(2);
try {
System.out.println(3);
System.out.println(4);
} catch (Exception e) {
System.out.println(5); // 실행되지 않는다.
} // try-catch의 끝
System.out.prinlt(6);
} // main메서드의 끝
}결과 : 1, 2, 3, 4, 5, 6
위의 예제에서는 예외가 발생하지 않았으므로 catch블럭의 문장이 실행되지 않았다.
다음의 예제는 위의 예제를 변경해서, try블럭에서 예외가 발생하도록 했다.
class ExceptionEx5 {
public static void main(String artgs[]) {
System.out.println(1);
System.out.prinln(2);
try {
System.out.println(3);
System.out.println(0/0);
System.out.println(4); // 실행되지 않는다.
} catch (ArithmeticException ae) {
System.out.println(5);
} // try-catch의 끝
System.out.println(6);
} // main메서드의 끝
}결과 : 1, 2, 3, 4, 5, 6
1.5 예외의 발생과 catch블럭
catch블럭은 괄호()와 블럭{} 두 부분으로 나눠져 있는데, 괄호()내에는 처리하고자 하는
예외와 같은 타입의 참조변수 하나를 선언해야한다.
예외가 발생하면, 발생한 예외에 해당하는 클래스의 인스턴스가 만들어 진다.
예제 8-5에서는 ArithmeticException이 발생했으므로 ArithmeticException인스턴스가 생성된다.
예외가 발생한 문장이 try블럭에 포함되어 있다면, 이 예외를 처리할 수 있는 catch블럭이 있는지 찾게 된다.
첫 번째 catch블럭부터 차례로 내려가면서 catch블럭의 괄호()내에 선언된 참조변수의 종류와 생성된
예외클래스의 인스턴스에 instanceof연산자를 이용해서 검사하게 되는데, 검사결과가 true인 catch블럭을
만날 때까지 검사는 계속된다.
검사결과가 true인 catch블럭을 찾게 되면 블럭에 있는 문장들을 모두 수행한 후에
try-catch문을 빠져나가고 예외는 처리되지만, 검사결과가 true인 catch블럭이 하나도 없으면 예외는
처리되지 않는다.
모든 예외 클래스는 Exception클래스의 자손이므로,
catch블럭의 괄호()에 Exception클래스 타입의 참조변수를 선언해 놓으면
어떤 종류의 예외가 발생하더라도 이 catch블럭에 의해서 처리된다.
class ExceptionsEx6 {
public static void main(String args[]) {
System.out.println(1);
System.out.println(2);
try {
System.out.println(3);
System.out.println(0/0); // 0으로 나눠서 ArithmeticException을 발생시킨다.
System.out.println(4); // 실행되지 않는다.
} catch (Exception e) { // ArithmeticException대신 Exception을 사용
System.out.println(5);
} // try-catch의 끝
System.out.println(6);
} // main메서드의 끝
}결과 : 1, 2, 3, 4, 5, 6
printStackTrace() 와 getMessage()
예외가 발생했을 때 생성되는 예외 클래스의 인스턴스에는 발생한 예외에 대한 정보가 있으며,
getMessage()와 printStack()을 통해서 이 정보들을 얻을 수 있다.
catch블럭의 괄호()에 선언된 참조변수를 통해 이 인스턴스에 접근할 수 있다.
이 참조변수는 선언된 catch블럭 내에서만 사용 가능하며, 자주 사용되는 메서드는 다음과 같다.
class ExceptionEx8 {
public static void main(String args[]) {
System.out.println(1);
System.out.println(2);
try{
System.out.print(3);
System.out.print(0/0); // 예외가 발생
System.out.print(4); // 실행되지 않는다.
} catch (ArithmeticException ㅁㄷ) {
ae.printStackTrace(); // 참조변수 ae를 통해 생성된 ArithmeticException인스턴스에 접근 가능
System.out.println("예외 메세지 : ae.getMessage());
} // try-catch의 끝
System.out.println(6);
} // main 메서드의 끝
}결과 : 1, 2, 3
java.lang.ArithmeticException; / by zero
at ExceptionEx8.main(ExceptionEx8.java:7)
예외 메세지 : / by zero
6
위 예제의 결과는 예외가 발생해서 비정상적으로 종료되었을 떄의 결과 비슷하지만
예외는 try-catch문에 의해 처리됐으며 프로그램은 정상적으로 종료됐다.
그 대신 ArithmeticException인스턴스의 printStackTrace()를 사용해서
호출 스택(call stack)에 대한 정보와 예외 메세지를 출력했다.
이처럼 try-catch문으로 예외처리를 해서 예외가 발생해도 비정상적으로 종료하지 않도록 해주는 동시에,
printStackTrace() 또는 getMessage()와 같은 메서드를 통해서 예외의 발생원인을 알 수 있다.
! printStackTrace(PrintStrem s) 또는 printStackTrace(PrintWriter s)를
사용하면 발생한 예외에 대한 정보를 파일에 저장할 수도 있다.
멀티 catch블럭
JDK1.7부터 여러 catch블럭을 '|'기호를 이용해서,
하나의 catch블럭을 합칠 수 있게 됐으며, 이를 '멀티 catch블럭'이라고 한다.
!멀티 catch블럭에 사용되는 '|'는 논리 연산자가 아니라 기호다.
try {
...
} catch (ExceptionA e) {
e.printStackTrace();
} catch (ExceptionB e2) {
e2.printStackTrace();
}=>
try {
...
} catch (Exception A | ExceptionB e) {
e.printStackTrace();
}만일 멀티 catch블럭의 '|'기호로 연결된 예외 클래스가 조상과 자손 관계에 있다면 컴파일 에러가 발생한다.
try {
...
} catch( ParentException | ChildException e) { // 에러 발생
e.printStackTrace();
}try {
...
} catch (ParentExcepion e) {
e.printStackTrace();
}그리고 멀티 catch는 하나의 catch블럭으로 여러 예외를 처리하는 것이기 때문에
발생한 예외를 멀티 catch블럭으로 처리하게 되었을 때, 멀티 catch블럭 내에서는
실제로 어떤 예외가 발생한 것이기 알 수 없다.
그래서 참조변수 e로 멀티 catch블럭에 '|'기호로 연결된
예외 클래스들의 공통 분모인 조상 예외 클래스에 선언된 멤버만 사용할 수 있다.
try {
...
} catch (ExceptionA |ExceptionB e) {
if (e instanceof ExceptionA) {
ExceptionA e1 = (ExceptionA)e;
e1.methodA(); // Ok, ExceptionA에 선언된 메서드 호출가능
} else { // if(e instanceof Exception B)
...
}
e.printStackTrace();
}필요하다면, 위의 코드처럼 instanceof로 어떤 예외가 발생한 것인지 확인하고 개별적으로 처리할 수 있다.
하지만 이렇게까지 해가면서 catch블럭을 합칠 일은 거의 없다.
마지막으로 멀티 catch블럭에 선언된 참조변수 e는 상수이므로 값을 변경할 수 없다는 제약이 있는데,
이 경우는 여러 catch블럭이 하나의 참조변수를 공유하기 때문에 생기는 제약으로 실제로 참조변수의 값을 바꿀 일은 없을 것이다.
1.6 예외 발생시키기
키워드 throw를 사용해서 프로그래머가 고의로 예외를 발생시킬 수 있으며, 방법은 아래의 순서를 따른다.
- 먼저 연산자 new를 이용해서 발생시키려는 예외 클래스의 객체를 만든 후
Exception e = new Exception("고의로 발생시켰음");- 키워드 throw를 이용해서 예외를 발생시킨다.
throw e;
class ExceptionEx9 {
public static void main(String args[]) [
try {
Exception e = new Exception("고의로 발생시켰음");
throw e; // 예외를 발생시킴
// throw new Exception("고의로 발생시켰음"); // 위 두 줄을 한 줄로 줄여 쓸 수 있다.
}catch (Exception e) {
System.out.println("에러 메세지 : "+e.getMessage());
e.printStackTrace();
}
System.out.println("프로그램이 정상 종료됨");
}
}에러 메세지 : 고의로 발생시킴
java.lang.Exception : 고의로 발생시킴
at ExceptionEx9.main(ExceptionEx9.java:4)
프로그램이 정상 종료됨
Exception인스턴스를 생성할 때, 생성자에 String을 넣어 주면,
이 String이 Exception 인스턴스에 메세지로 저장된다.
이 메세지는 getMessage()를 이용해서 얻을 수 있다.
class ExceptionEx10 {
public static void main(String[] args) {
throw new Exception(); // Exception을 고의로 발생시킨다.
}
}결과 : ExceptionEx10.java:4: unreported exception java.lang.Exception; must be caught or
declared to be thrown
throw new Exception();
1 error
이 예제를 작성한 후 컴파일 하면, 위 같은 같은 에러가 발생하며 컴파일이 완료되지 않는다.
예외처리가 되어야 할 부분에 예외처리가 되어 있지 않다는 에러다.
위 결과에서 알 수 있는 것처럼, 앞서 다룬 'Exception클래스들(Exception클래스와 그 자손들)'이
발생할 가능성이 있는 문장들에 대해 예외처리를 해주지 않으면 컴파일도 되지 않는다.
class ExceptionEx11 {
public static void main(String[] args)
{
throw new RuntimeException(); // RuntimeException을 고의로 발생시킴
}
}=>
Exception in thread"main"java.lang.RuntimeException
at ExceptionEx11.main(ExceptionEx11.java:4)
위 코드는 예외처리를 하지 않았는데도 불구하고 이전의 예제와 달리 성공적으로 컴파일될 것이다.
그러나 실행하면, 위 실행결과처럼 RuntimeException이 발생해서 비정상적으로 종료된다.
이 예제가 명백히 RuntimeException을 발생시키는 코드를 갖고 있고,
이에 대한 예외처리를 하지 않았음에도 불구하고 성공적으로 컴파일됐다.
앞에서 본 것처럼 'RuntimeException클래스와 그 자손(RuntimeException클래스들)'에 해당하는 예외는
프로그래머에 의해서 실수로 발생하는 것들이기 때문에 예외처리를 강제하지 않는 것이다.
만약 RuntimeException클래스에 속하는 예외가 발생할 가능성이 있는 코드에도
예외처리를 필수로 해야 한다면, 아래와 같이 참조 변수와 배열이 사용되는 모든 곳에 예외처리를 해줘야 할 것이다.
try {
int[] arr = new int[10];
System.out.println(arr[0]);
} catch(ArrIndexOutOfBoundsException ae) {
...
} catch(NullPointerException ne) {
...
}컴파일러가 예외처리를 확인하지 않는 RuntimeException클래스들은 'unchecked예외'라고 부르며,
예외처리를 확인하는 Exception클래스들은 'checked예외'라고 부른다.
1.7 메서드에 예외 선언하기
예외를 처리하는 방법에는 지금까지 배워 온 try-catch문을 사용하는 것 외에, 예외를 메서드에 선언하는 방법이 있다.
메서드에 예외를 선언하려면, 메서드의 선언부에 키워드 throw를 사용해서 메서드 내에서 발생할 수 있는 예외를 적어주기만 하면 된다.
예외가 여러 개일 경우에는 쉼표(,)로 구분한다.
void method() throws Exception1, Exception2, .. ExceptionN {
// 메서드 내용
}_! 예외를 발생시키는 키워드 throw와 예외를 메서드에 선언할 때 쓰이는 throw를 잘 구별해야 한다.
만약 아래처럼 모든 예외의 최고 조상인 Exception클래스를 메서드에 선언하면,
이 메서드는 모든 종류의 예외가 발생할 가능성이 있다는 뜻이다.
void method() throws Exception{
// 메서드 내용
}이렇게 예외를 선언하면, 이 예외뿐만 아니라 자손 타입의 예외까지도 발생할 수 있다는 점에 주의해야 한다.
앞에서 본 오버라이딩에서 살펴본 것과 같이, 오버라이딩할 때는 단순히 선언된 예외의 개수가 아니라 상속관계까지 고려해야 한다.
메서드의 선언부에 예외를 선언함으로써 메서드를 사용하려는 사람이 메서드의 선언부를 봤을 때,
이 메서드를 사용하기 위해서는 어떤 예외들이 처리되어져야 하는지 쉽게 알 수 있다.
기존의 많은 언어들에서는 메서드에 예외 선언을 하지 않기 때문에,
어떤 상황에 어떤 종류의 예외가 발생할 가능성이 있는지 충분히 예측하기 힘들기 때문에 그에 대한 대비를 하는 것이 어려웠다.
자바에서는 메서드를 작성할 때 메서드 내에서 발생할 가능성이 있는 예외를 메서드의 선언부에 명시해서 이 메서드를 사용하는 쪽에서는 이에 대한 처리를 하도록 강요하기 때문에, 프로그래머들의 짐을 덜어 주는 것은 물론이고 보다 견고한 프로그램 코드를 작성할 수 있도록 도와준다.
메서드에 예외를 선언할 때 일반적으로 RuntimeException클래스들을 적지 않았다.
이들을 메서드 선언부의 throws에 선언한다고 해서 문제가 되지 않지만,
보통 반드시 처리해줘야 하는 예외들만 선언한다.
이처럼 Java API문서를 통해 사용하고자 하는 메서드의 선언부와 'Throws:'를 보고,
이 메서드에서는 어떤 예외가 발생할 수 있으며
반드시 처리해줘야 하는 예외는 어떤 것들이 있는지 확인하는 것이 좋다.
사실 예외를 메서드의 throw에 명시하는 것은 예의를 처리하는 것이 아니라,
자신(예외가 발생할 가능성이 있는 메서드)을 호출한 메서드에게 예외를 전달해서 예외처리를 떠맡기는 것이다.
예외를 전달받은 메서드가 또다시 자신을 호출한 메서드에게 전달할 수 있으며,
이런 식으로 계속 호출스택에 있는 메서드들을 따라 전달되다가 제일 마지막에 있는 main메서드에서도 예외가 처리되지 않으면,
main메서드마저 종료되어 프로그램이 전체가 종료된다.
class ExceptionEx12 {
public static void main(String[] args) throws Exception {
method1(); // 같은 클래스내의 statice멤버이므로 객체생성없이 직접 호출 가능
} // main 메서드의 끝
static void method() throws Exception {
method2();
} // method1의 끝
static void method2() throws Exception {
throw new Exception();
} // method2의 끝
}실행결과
java.lang.Exception
at ExceptionEx12.method2(ExceptionEx12.java:11)
at ExceptionEx12.method1(ExceptionEx12.java:7)
at ExceptionEx12.main(ExceptionEx12.java:3)
위 실행결과를 보면 프로그램의 실행도중 java.lang.Exception이 발생해서 비정상적으로 종료했다는 것과
예외가 발생했을 때 호출스택(call stack)의 내용을 알 수 있다.
위 결과로부터 다음과 같은 사실을 알 수 있다.
- 예외가 발생했을 때, 모두 3개의 메서드(main, method1, method2)가 호출스택에 있었으며,
- 예외가 발생한 곳은 제일 윗줄에 있는 method2()라는 것과
- main메서드가 method1()을, 그리고 method1()은 method2()를 호출했다는 것을 알 수 있다.
위 코드를 보면 method2()에서 'throw new Exception();' 문장에 의해서
예외가 강제적으로 발생했으나 try-catch문으로 예외처리를 해주지 않았으므로,
method2()는 종료되면서 예외를 자신을 호출한 method1()에게 넘겨준다.
method1()에서도 역시 예외처리를 해주지 않았으므로 종료되면서 main메서드에게 예외를 넘겨준다.
그러나 main메서드에서 조차 예외처리를 해주지 않았으므로 main메서드가 종료되어
프로그램이 예외로 인해 비정상적으로 종료된다.
이처럼 예외가 발생한 메서드에서 예외처리를 하지 않고 자신을 호출한 메서드에게
예외를 넘겨줄 수는 있지만, 이것으로 예외가 처리된 것은 아니고 예외를 단순히 전달만 하는 것이다.
결국 어느 한 곳에서는 반드시 try-catch문으로 예외처리를 해줘야 한다.
class ExceptionEx13 {
public static void main(String[] args) {
method1(); // 같은 클래스내의 static멤버므로 객체생성없이 직접 호출가능
} // main 메서드의 끝
static void method1() {
try {
throw new Exception();
} catch (Exception e) {
System.out.println("method1 메서드에서 예외처리가 됐다.");
e.printStackTrace();
}
} // method1의 끝
}method1 메서드에서 예외가 처리됐습니다.
java.lang.Exception
at ExceptionEx13.method1(ExceptionEx13.java:8)
at ExceptionEx13.main(ExceptionEx13.java:3)
예외 처리됐지만, printStackTrace()를 통해 예외에 대한 정보를 화면에 출력했다.
예외가 method1()에서 발생했으며, main메서드가 method1()을 호출했다.
1.8 finally 블럭
finally 블럭은 예외의 발생여부에 상관없이 실행되야할 코드를 포함시킬 목적으로 사용된다.
try-catch문의 끝에 선택적으로 덧붙여 사용할 수 있으며, try-catch-finally의 순서로 구성된다.
try {
// 예외가 발생할 가능성이 있는 문장들을 넣는다.
} catch (Exception1 e1) {
// 예외처리를 위한 문장을 적는다.
} finally {
// 예외의 발생여부에 관계없이 항상 수행되어야하는 문장들을 넣는다.
// finally블럭은 try-catch문의 맨 마지막에 위치해야한다.
}예외가 발생한 경우에는 'try->catch->finally'의 순으로 실행되고, 예외가 발생하지 않은 경우에는
'try->finally'의 순으로 실행된다.
class FinallyTest {
try {
stratInstall(); // 프로그램 설치에 필요한 준비한다.
copyFiles(); // 파일들을 복사한다.
deleteTempFiles(); // 프로그램 설치에 사용된 임시파일들을 삭제한다.
} catch (Exception e) {
e.printStackTrace();
deleteTempFiles(); // 프로그램 설치에 사용된 임시파일들을 삭제한다.
} // try-catch의 끝
} // main의 끝
static void startInstall() {
/* 프로그램 설치에 필요한 준비를 하는 코드를 적는다. */
}
static void copyFiles() { /* 파일들을 복사하는 코드를 적는다.*/ }
static void deleteTempFiles() { /* 임시파일들을 삭제하는 코드를 적는다.*/ }
}_! startinstall(), copyFiles(), deleteTempFiles()에 주석문 이외에는 아무런 문장이 없지만,
각 메서드의 의미에 해당하는 작업을 수행하는 코드들이 작성되어 있다고 가정한다.
위 코드가 하는 일은 프로그램 설치를 위한 준비를 하고 파일들을 복사하고
설치가 완료되면, 프로그램을 설치하는데 사용된 임시파일들을 삭제하는 순서로 진행된다.
프로그램의 설치과정 중에 예외가 발생하더라도, 설치에 사용된 임시파일들이 삭제되도록
catch블럭에 deleteTempFiles()메서드를 넣었다.
결국 try블럭의 문장을 수행하는 동안에(프로그램을 설치하는 과정에), 예외의 발생여부에
관계없이 deleteTempFiles()메서드는 실행되어야 하는 것이다.
이럴 때 finally블럭을 사용하면 좋다.
아래의 코드는 위의 예제를 finally블럭을 사용해서 변경한 것이며, 두 예제의 기능은 동일하다.
1.9 자동 자원 반환 - try - with - resources문
JDK1.7부터 try-with-resources문이라는 try-catch문의 변형이 새로 추가됐다.
이런 것도 있다는 정도로만 가볍게 봐뒀다가 필요할 때 참고하기 바란다.
주로 입출력에 사용되는 클래스 중에서는 사용한 후에 곡 닫아 줘야 하는 것들이 있다.
그래야 사용했던 자원(resources)이 반환되기 때문이다.
try{
fis = new FileInputStream("score.dat");
dis = new DataInputStream(fis);
...
} catch (IOException ie) {
ie.printStackTrace();
} finally {
dis.close(); // 작업 중에 예외가 발생하더라도, dis가 닫히도록 finally 블럭에 넣음
}위 코드는 DataInputStream을 사용해서 파일로부터 데이터를 읽는 코드인데,
데이터를 읽는 도중에 예외가 발생해도 DataInputStream이 닫히도록 finally블럭 안에 close()를 넣었다.
여기까지는 별 문제가 없어 보이는데, 진짜 문제는 close()가 예외를 발생시킬 수 있다는데 있다.
그래서 위의 코드는 아래와 같이 해야 올바른 것이 된다.
try {
fis = new FileInputStream("score.dat");
dis = new DateInputStrem(fis);
} catch (IOException ie) {
ie.printStackTrace();
} finally {
try {
if(dis!=null)
dis.close();
} catch(IOexception ie) {
ie. printStachTrace();
}
}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();
System.out.println(score);
sum += score;
}
} catch (EOFException e) {
System.out.println("점수의 총합은" + sum +"입니다.");
} catch (IOException ie) {
ie.printStackTrace();
}try-with-resources문의 괄호()안에 객체를 생성하는 문장을 넣으면,
이 객체는 따로 close()를 호출하지 않아도 try블럭을 벗어나는 순간 자동적으로 close()가 호출된다.
그 다음에 catch블럭 또는 finally블럭이 수행된다.
! try블럭의 괄호()안에 변수를 선언하는 것도 가능하며, 선언된 변수를 try블럭 내에서만 사용할 수 있다.
이처럼 try-with-resources문에 의해 자동으로 객체의 close()가 호출될 수 있으려면,
클래스가 AutoCloseable라는 인터페이스를 구현한 것이어야 한다.
1.10 사용자 정의 예외 만들기
기존의 정의된 예외 클래스 외에 필요에 따라 프로그래머가 새로운 예외 클래스를 정의해서 사용할 수 있다.
보통 Exception클래스 또는 RuntimeException클래스로부터 상속받아 클래스를 만들지만,
필요에 따라서 알맞은 예외 클래스를 선택할 수 있다.
! 가능하면 새로운 예외 클래스를 만들기보다 기존의 예외클래스를 활용한다.
class MyException extends Exception {
MyException(String msg) { // 문자열을 매개변수로 받는 생성자
super(msg); // 조상인 Exception클래스의 생성자를 호출한다.
}
}Exception 클래스로부터 상속받아 MyException클래스를 만들었다.
필요하다면 멤버 변수나 메서드를 추가할 수 있다.
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(msg, 100) // ERR_CODE를 100(기본값)으로 초기화한다.
}
public int getErrCode() { // 에러 코드를 얻을 수 있는 메서드도 추가했다.
return ERR_CODE; // 이 메서드는 주로 getMessage()와 함께 사용될 것이다.
}
} 이전의 코드를 좀 더 개선하여 메세지뿐만 아니라 에러코드 값도 저장할 수 있도록 ERR_CODE와
getErrCode()를 MyException클래스의 멤버로 추가했다.
이렇게 함으로써 MyException이 발생했을 때, catch블럭에서 getMessage()와 getErr Code()를
사용해서 에러코드와 메세지를 모두 얻을 수 있을 것이다.
기존의 예외 클래스는 주로 Exception을 상속받아서 'checked예외'로 작성하는 경우가 많지만,
요즘은 예외처리를 선택적으로 할 수 있도록 RuntimeException을 상속받아 작성하는 경우가 많다.
'checked예외'는 반드시 예외처리를 해줘야 하기 때문에
예외처리가 불필요한 경우에도 try-catch문을 넣어서 코드가 복잡해지기 때문이다.
1.11 예외 되던지기(exception re-throwing)
한 메서드에서 발생할 수 있는 예외가 여럿인 경우, 몇 개는 try-catch문을 통해서
메서드 내에서 자체적으로 처리하고, 그 나머지는 선언부에 지정해서 호출한 메서드에서 처리하도록 함으로써,
양쪽에서 나눠서 처리되도록 할 수 있다.
그리고 심지어는 단 하나의 예외에 대해서도 예외가 발생한 메서드와 호출한 메서드, 양쪽에서 처리하도록 할 수 있다.
이것은 예외를 처리한 후에 인위적으로 다시 발생시키는 방법을 통해서 가능한데,
이것을 '예외 되던지기(exception re-throwing)'라고 한다.
먼저 예외가 발생할 가능성이 있는 메서드에서 try-catch문을 사용해서 예외를 처리해주고
catch문에서 필요한 작업을 행한 후에 throw문을 사용해서 예외를 다시 발생시킨다.
다시 발생한 예외는 이 메서드를 호출한 메서드에게 전달되고
호출한 메서드의 try-catch문에서 예외를 또다시 처리한다.
이 방법은 하나의 예외에 대해서 예외가 발생한 메서드와
이를 호출한 메서드 양쪽 모두에서 처리해줘야 할 작업이 있을 때 사용된다.
이 때 주의할 점은 예외가 발생할 메서드에서는 try-catch문을 사용해서 예외처리를 해줌과
동시에 메서드의 선언부에 발생할 예외를 throw에 지정해줘야 한다는 것이다.
class ExceptionEx17 {
public static void main(String[] args) {
try {
method1();
} catch (Exception e) {
System.out.println("main메서드에서 예외가 처리됐습니다.");
}
} // main 메서드의 끝
static void method1() throws Exception{
try {
throw new Exception();
} catch (Exception e) {
System.out.println("method1메서드에서 예외가 처리됐다.");
throw e; // 다시 예외를 발생시킨다.
}
} // method 메서드의 끝
}실행결과 : method1 메서드에서 예외가 처리됐습니다.
main 메서드에서 예외가 처리됐습니다.
결과에서 본 것처럼 method1()과 main메서드 양쪽의 catch블럭이 모두 수행되었음 알 수 있다.
method1()의 catch블럭에서 예외를 처리하고도 throw문을 통해 다시 예외를 발생시켰다.
그리고 예외를 main메서드를 한 번 더 처리했다.
반환값이 있는 return문의 경우, catch블럭에도 return문이 있어야 한다.
예외가 발생했을 경우에도 값을 반환해야 하기 때문이다.
1.12 연결된 예외(chained exception)
한 예외가 다른 예외를 발생시킬 수도 있다.
예를 들어 예외 A가 예외 B를 발생시켰다면, A를 B의 '원인 예외(cause exception)'라고 한다.
아래의 코드는 앞서 다룬 코드를 변경한 것으로, SpaceException을
원인 예외로 하는 InstallException을 발생시키는 방법을 보여준다.
try {
startInstall(); // SpaceException 발생
copyFiles();
} catch (SpaceException e) {
InstallException ie = new installException("설치중 예외발생") // 예외 생성
ie.initCause(e); // InstallException의 원인 예외를 SpaceException으로 지정
throw ie; // InstallException을 발생시킨다.
} catch (MemoryException me)
...먼저 InstallException을 생성한 후, initCause()로 SpaceException을
InstallException의 원인 예외로 등록한다. 그리고 'throw'로 이 예외를 던진다.
initCause()는 Exception클래스의 조상인 Throwable클래스에 정의되어 있기 때문에 모든 예외에서 사용가능하다.
Throwable initCause (Throwable cause) : 지정한 예외를 원인 예외로 등록
Throwable getCause() 원인 예외를 반환
발생환 예외를 그냥 처리하면 되는데 굳이 왜 원인 예외로 등록해서 다시 예외를 발생시킬까
여러가지 예외를 하나의 큰 분류의 예외로 묶어서 다루기 위해서다.
그렇다고 아래처럼 installException을 SpaceException과 MemoryException의 조상으로 해서
catch블럭을 작성하면, 실제로 발생한 예외가 어떤 것인지 알 수 없다는 문제가 생긴다.
그리고 SpaceException과 MemoryException의 상속관계를 변경해야 한다는 것도 부담이 된다.
try {
startInstall(); // SpaceException 발생
copyFiles();
} catch (InstallException e) { // InstallException은
e.printStackTrace(); // SpaceException과 MemoryException의 조상
}그래서 생각한 것이 예외가 원인 예외를 포함할 수 있게 됐다.
이렇게 하면, 두 예외는 상속관계는 아니어도 상관없다.
public class Throwable implements Serializable {
...
private Throwable cause = this; // 객체 자신(this)을 원인 예외로 등록
...
}또 다른 이유는 checked예외를 unchecked예외로 바꿀 수 있도록 하기 위함이다.
checked예외로 예외처리를 강제한 이유는 프로그래밍 경험이
적은 사람도 보다 견고한 프로그램을 작성할 수 있도록 유도하기 위한 것이었는데,
지금은 자바가 처음 개발되던 1990년대와 컴퓨터 환경이 많이 달라졌다.
그래서 checked예외가 발생해도 예외를 처리할 수 없는 상황이 하나둘 발생하기 시작했다.
이럴 떄 할 수 있는 일은 의미없는 try-catch문을 추가하는 것뿐인데,
checked예외를 unchecked예외로 바꾸면 예외처리가 선택적이 되므로 억지로 예외처리를 하지 않아도 된다.
static void stratinstall() throws SpaceException, MemoryException {
if(!enoughSpace()) // 충분한 설치 공간이 없으면
throw new SpaceException("설치할 공간이 부족합니다.");
if(!enoughMemory()) // 충분한 메모리가 없으면
throw new MemoryException("메모리가 부족합니다.");
}static void startInstall() throws SpaceException {
if(!enoughSpace()) // 충분한 설치 공간이 없으면..
throw new SpaceException("설치할 공간이 부족합니다.");
if(!enoughMemory()) // 충분한 메모리가 없으면...
throw new RuntimeException(new MemoryException("메모리가 부족합니다."));
} // startInstall메서드의 끝MemoryException은 Exception의 자손이므로 반드시 예외를 처리해야하는데,
이 예외를 RuntimeException으로 감싸버렸기 대문에 unchecked예외가 됐다.
그래서 더 이상 startInstall()의 선언부에 MemoryException을 선언하지 않아도 된다.
참고로 위 코드에서는 initCause()대신 RuntimeException의 생성자를 사용했다.
RuntimeException(Throwable cause) // 원인 예외를 등록하는 생성자