[Java] Checked, Unchecked Exception

 

사진 출처 : https://www.nextree.co.kr/p3239/

 

자바 실행 시 발생할 수 있는 프로그램 오류를 Error와 Exception두가지로 구분한다.

Error

시스템에 비정상적인 상황이 발생했을 경우 발생

메모리 부족(OutOfMemory Error), 스택오버플로우(StackOverflowError)와 같이 복구할 수 없는 것

 

Exception

프로그램 실행 중 개발자의 실수로 예기치 않은 상황이 발생

https://www.nextree.co.kr/p3239/

 

컴파일러가 에러처리를 확인하지 않는 RuntimeException클래스들은 unchecked 예외라고 하고,

예외처리를 확인하는 Exception 클래스들은 checked예외라고 한다.

Checked Exception

반드시 에러 처리를 해야 한다(try-catch or thorw)

Exception클래스의 하위

● FileNotFoundException : 존재하지 않는 파일의 이름 입력

● ClassNotFoundException : 실수로 클래스의 이름을 잘못 적음

롤백되지 않고 트랜잭션이 commit까지 완료

 

문법적 오류로 인해 예외 발생 -> 컴파일 안됨

 

SQLException, FileIOException 과 같은 에러를 핸들링하지 않는다면 프로그램이 종료되거나 시스템이 멈출 수 있다.

파일을 만들었을 때 에러 핸들링을 안하면 쓸모없는 덤프 파일 같은 것이 계속 생겨 시스템이 멈출 수 있다.

SQL 익셉션도 데이터 베이스에서 발생한 에러를 핸들링하지 않으면 DB 정확성에 문제가 될 수 있다.

IDE에서 빨간 줄로 try-catch안했다고 알려준다. → 해결 안하면 컴파일 안된다.

Unchecked Exception

에러 처리를 강제하지 않음

RuntimeException클래스의 하위

● ArrayIndexOutOfBoundsException : 배열의 범위를 벗어난 인덱스 참조

● NullPointerException : Null참조

롤백된다.

 

컴파일이 완료되고 문법적 오류는 없지만 널참조, 범위에 벗어난 인덱스 참조 등 개발자의 실수로 인해 발생하는 오류로 발생하는 Exception이다.

프로그램이 실행하면서 발생하는 바뀌는 값이기에 런타임 시에 에러인지 알 수 있다.

 

Unchecked Exception은 예외 처리를 강제하지 않을까?

Unchecked 예외가 에러 처리를 강제해야 한다면 배열의 원소를 출력하는데도 try-catch문을 꼭 사용해야 한다.

Runtime Exception은 개발자들에 의해 실수로 발생하는 것들이기 때문에 에러를 강제하지 않는다.

피할 수 있지만 개발자가 부주의해서 발생하는 경우이기 때문이다. 예상하지 못했던 예외상황에서 발생하는 것이 아니기 때문에 굳이 catch나 throws를 사용하지 않아도 되도록 만든 것이다.

 

런타임 예외의 보편화

일반적으로 체크 예외가 일반적인 예외를 다루고, 언체크 예외는 시스템 장애나 프로그램상의 오류에 사용한다고 했다.

 

자바가 처음 만들어질 때 많이 사용하던 애플린, AWT, 스윙을 사용한 독립형 애플리케이션에서 자바 엔터프라이즈 서버환경으로 이동되었다.

 

● 독립형 애플리케이션

통제 불가능한 시스템 예외라고 할지라도 애플리케이션의 작업이 중단되지 않게 해주고 상황을 복구해야 했다.

예를 들어 워드의 파일 열기 기능에서 사용자가 입력한 이름에 해당하는 파일을 찾을 수 없다고 애플리케이션이 종료돼버리게 할 수 없다.

 

● 자바 엔터프라이즈 서버환경

수많은 사용자가 동시에 요청을 보내고 각 요청이 독립적인 작업으로 취급된다. 하나의 요청을 처리하는 중에 예외가 발생하면 해당 작업만 중단시키면 그만이다. 

독립형 애플리케이션과 달리 서버의 특정 계층에서 예외가 발생했을 때 작업을 일시 중지하고 사용자와 바로 커뮤니케이션하면서 예외상황을 복구할 수 있는 방법이 없다.

차라리 애플리케이션 차원에서 예외상황을 미리 파악하고, 예외가 발생하지 않도록 차단하는게 좋다.

또는 프로그램의 오류나 외부 환경으로 인해 예외가 발생하는 경우라면 해당 요청의 작업을 취소하고 서버 관리자나 개발자에게 통보해주는 편이 낫다.

 

자바의 환경이 서버로 이동하면서 체크 예외의 활용도와 가치는 떨어지고 있다.

throws Exception으로 아무런 의미 없는 메소드들이 나올 수 있다.

그래서 대응이 불가능한 체크 예외라면 빨리 런타임 예외로 전환해서 던지는게 낫다.

 

체크 예외가 예외처리를 강제하는 것 때문에 예외 블랙홀이나 무책임한 throws같은 코드가 남발되었다. 

 

자바 초기부터 있었던 JDK의 API와 달리 최근에 등장하는 표준 스펙 또는 오픈소스 프레임워크에서는 API가 발생시키는 예외를 체크 예외 대신 언체크 예외로 정의하는 것이 일반화되고 있다.

예전에는 복구할 가능성이 조금이라도 있다면 체크 예외로 만든다고 생각했는데, 지금은 항상 복구할 수 있는 예외가 아니라면 일단 언체크 예외로 만드는 경향이 있다.

 

언체크 예외도 try-catch로 복구하거나 처리할 수 있다.

복구 불가능한 상황도 RuntimeException 등으로 포장해서 던져야 하니 API차원에서 런타임 예외를 던지도록 만드는 것이다.

 

 

 

Transaction

쪼갤 수 없는 여러 작업들을 논리적으로 묶은 최소 단위

 

특징

● 원자성(Atomicity)

트랜잭션의 연산은 DB에 모두 반영되던지, 모두 반영되지 않아야 한다.

하나라도 실패한다면 앞서 성공한 것들을 원상 복구 시켜야 한다.

 

● 일관성(Consistency)

트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다.

 

● 독립성(Isolation)

어떤 트랜잭션도 다른 트랜잭션의 작업에 끼어들 수 없다.

 

● 지속성(Durability)

트랜잭션이 완료된다면, 결과는 영구적이어야 한다.

 

트랜잭션은 로직을 수행하고 모든 로직이 성공적으로 수행되었을 경우에는 모든 결과를 DB에 일괄적으로 commit하고, 하나라도 실패한다면 모든 작업을 원상 복구(rollback)시킵니다.

 

 

 

 

 

참고

토비의 스프링

https://devlog-wjdrbs96.tistory.com/351

https://www.nextree.co.kr/p3239/

https://velog.io/@byeongju/Spring-Transaction%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90