1. 예외 클래스의 구조와 예외 클래스
자바에서 예외처리는 프로그램에서 어떤 예외가 발생했을 때 프로그램이 죽거나 오작동하지 않고 유연하고 안정성 있게 동작 할 수 있게끔 처리하는 기술입니다.
먼저 예외클래스의 구조는 아래 그림과 같습니다.
클래스의 최상위 클래스인 오브젝트 클래스를 상속받고 있으며 Error과 Exception의 최상위 클래스인 Throwable 클래스를 상속받고 있습니다.
예외클래스의 최상위 클래스는 Exception 클래스로 그 하위에는 여러 예외클래스들이 구성되어 있는데 그 중 RuntimeException 클래스는 하위 클래스들을 가지고 있습니다.
- Checked Exception과 UnChecked Exception
Exception 클래스 하위에 여러 예외 클래스 중 Runtime Exception은 하위 클래스들을 가지고 있는데 이것들을 Unchecked Exception라 합니다.
즉, Exception 클래스 하위에 Runtime Exception을 제외한 모든 클래스는 Checked Exception이며 Runtime Exception을 포함한 그 하위 클래스들을 UnChecked Exception이라 합니다.
그렇다면 이 둘의 차이점은 무엇일까요?
Checked Exception의 대표적으로는 IOException, ClassNotFoundException, SQLException등이 있습니다.
Checked Exception은 반드시 명시적으로 예외처리를 해야하는 특징이 있습니다. 해당 Exception이 발생하는 곳에서 예외처리를 해야합니다.
즉 Checked Exception의 확인시점은 컴파일 단계입니다.
때문에 이클립스나 기타 프로그래밍 툴을 사용하여 소스를 작성한다면 Checked Exception이 발생할 곳에 예외처리를 하지 않으면 프로그래밍 툴에서 오류 표시가 나타나게 됩니다.
Checked Exception은 보통 프로그램 흐름 상의 예외가 발생할 수 있는 예외들입니다.
그렇기 때문에 프로그래밍에 있어서 개발자에게 예외처리의 강제성이 부여됩니다.
또한 이러한 강제성에 의해서 의도한 것인지는 모르겠으나 트랜잭션 처리 시 Checked Exception이 발생할 경우 RollBack처리를 하지 않습니다. (이미 개발자가 예외처리를 했으닌까?)
UnChecked Exception의 대표적으로는 NullPointException, ArrayIndexOutBoundsException, ArithmeticException, NumberFormatException 등이 있습니다.
UnChecked Excption은 명시적인 예외처리를 강제하지 않는 특징이 있습니다. 해당 Exception이 발생하는 곳에 예외처리를 하지 않아도 컴파일러는 에러처리를 하지 않습니다.
즉 이 Checked Exception의 확인시점은 실행단계입니다.
때문에 이클립스나 기타 프로그래밍 툴을 사용하여 소스를 작성한다면 UnChecked Exception이 발생할 곳에 예외처리를 하지 않아도 프로그래밍 툴에서 오류 표시없이 정상 컴파일 됩니다.
그렇기 때문에 보통 개발자의 실수에 의한 예외상황 발생할 수 있는 예외들입니다.
또한 예외처리에 대한 강제성이 없기 때문에 트랜젝션 처리 시 예외처리가 되지 않고 프로그램이 종료되는 상황이 발생할 수도 있는 가정에 의해(?) Unchecked Exception 발생 시 Rollback처리를 합니다. (이건 지극히 저의 생각입니다 :) )
아래는 이 내용을 정리한 표 입니다.
2. 실행예외(Runtime Exception)
실행예외는 예외처리에 대한 컴파일러의 의한 강제성은 없지만 해당 예외가 발생하면 프로그램이 종료되거나 오작동 하기 때문에 어떤 오류가 발생하는지 예상하고, 발생했다면 오류 메세지를 확인하여 예외처리 할 수 있도록 해야 합니다.
실행 예외의 종류에 대해서 알아보죠.
- NullPointException
해당 예외는 객체가 null인 상태에서 인스턴스 메서드를 호출할 때 발생하는 에러입니다.
소스를 보면 str = null인데 아래라인에서 .toString() 인스턴스 메소드를 호출을 하고 있어서 nullPointException이 발생했습니다.
이뿐만 아니라
- 객체가 null일 때 필드를 엑세스 하거나 수정하려는 경우
- 빈 배열 객체에 길이 속성을 가져오려 하는 경우
- 배열 index 중 null을 엑세스 하려거나 수정하려는 경우
등이 있습니다.
- NumberFormatException
NumberFormatException은 문자형에서 숫자형으로 형변환 할 시 숫자형으로 변환 할 수 없을 경우 발생합니다.
소스를 보면 str1은 String형이지만 값이 1이라서 숫자형으로 형변환 할 수 있는 반면 str2는 값이 1#이라 숫자로 형변환 할 수 없어 NumberFormatException이 발생한 걸 볼 수 있습니다.
아래는 실행예외(RunTimeException)들을 정리 해봤습니다.
RuntimeException 종류
|
내용
|
ArithmeticException
|
산술연산 중 0으로 나누면 발생
|
ArrayStoreException
|
잘못된 유형의
객체를 객체배열에 저장하려고 할 때 발생
|
BufferOverflowException
|
데이터를 PUT 할 때 버퍼의 limit에 이르렀을 때 발생
|
BufferUnderflowException
|
데이터를 GET 할 때 버퍼의 limit에 이르렀을 때 발생
|
CannotRedoException
|
UndoableEdit에 redo()를
실행했지만 실행 할 수 없을 경우 발생
|
CannotUndoException
|
UndoableEdit에 undo()를
실행했지만 실행 할 수 없을 경우 발생
|
ClassCastException
|
어느 객체를 상속관계에
없는 클래스에 캐스트 하려고 했을 경우 발생
|
ConcurrentModificationException
|
동기화 관련 에러로
데이터에 대한 무결성 입증이 되지 않을 때 발생
|
EmptyStackException
|
Stack이 비어있을 경우 발생
|
IllegalArgumentException
|
부정한 인수, 또는 부적절한 인수를 메서드에 건네준 것을 나타내기 위해서 발생
|
IllegalMonitorStateException
|
멀티스레드의 모니터
상태가 부정일 때
|
IllegalPathStateException
|
특정 오퍼레이션에
대해 path가 무효인데 그 오퍼레이션이 실행되었을 경우 발생
|
IllegalStateException
|
메서드가 요구
된 처리를 하기 위해 적합한 상태에 있지 않을때 발생
|
ImagingOpException
|
BufferedImageOp
또는 RasterOp 필터 메서드가 이미지를 처리할 수 없는 경우 발생
|
IndexOutOfBoundsException
|
어떤 종류의 인덱스가
범위 외인 것을 나타내기 위해 발생
|
MissingResourceException
|
리소스가 결핌하고
있는 것을 통지
|
NegativeArraySizeException
|
배열을 선언할
때 음수의 크기로 지정할 경우 발생
|
NoSuchElementException
|
Next
Element에 요소가 없으면 발생
|
NullPointerException
|
참조변수가 null로 초기화 된 상황에서 메서드를 호출하는 경우 발생
|
ProfileDataException
|
ICC_Profile
오브젝트의 엑세스 또는 처리에 에러가
발생했을 경우 발생
|
ProviderException
|
프로바이더 예외에
대한 실행 시 발생
|
RasterFormatException
|
Raster에 무효인 레이아웃 정보가 있는 경우 발생
|
SecurityException
|
시큐리티 매니저에
의해 시큐리티 위반시 발생
|
SystemException
|
모든 CORBA 표준 예외의 루트 클래스
|
3. 예외처리 코드
예외처리는 자바에서 try - catch문을 사용합니다. 아래는 try - catch문의 구조를 설명핸 이미지 입니다.
try 영역에는 예외가 발생 할 수 있는 소스를 입력하고
catch 영역에는 예외가 발생했을 경우 처리 할 소스 입력합니다. catch문에 여러 Exception을 기술하여 분기처리 할 수도 있지만 예외처리 최상위 클래스인 Exception 클래스 하나만 기술하여 전부 처리 할 수도 있습니다.
finally는 이름처럼 마지막에 실행하는 영역인데 작성해도 되고 안해도 되는 필요에 의해 작성하는 영역입니다.
작성을 하게 되면 예외가 발생하든 하지 않든 무조건 실행되는 영역입니다.
위 소스는 분기처리 하여 NumberFormat Exception을 처리하는 소스입니다.
7번라인에 값이 ABC인 String형을 숫자형으로 형변환을 시도하고 있습니다.
당연히 NumberFormatException이 발생할 것이고 NumberFormatException을 명시한 8번라인 catch문에서 예외처리가 된 것을 확인 할 수 있습니다.
분기처리 모습을 보니 마치 if문과도 비슷해 보이는 군요
위 소스는 5번라인에서 5를 0으로 나누어 강제로 ArithmeticException을 발생시켰습니다.
catch문에는 ArithmeticException을 분기처리 하지 않았지만 예외처리 최상위 클래스인 10번라인 Exception에서 예외를 캐치하여 예외처리 된 모습입니다.
댓글 쓰기