관리 메뉴

공부한것들을 정리하는 블로그 입니다.

자바 예외처리, 에러 핸들링에 대해 짧게 정리 본문

경력 실무경험/생각해볼만한 주제

자바 예외처리, 에러 핸들링에 대해 짧게 정리

호 두 2023. 4. 28. 19:41
반응형

* 해당 글은 계속 수정 예정입니다.
최초 작성일 2022.06
마지막 수정일 2023.04




# 프로그램에서의 오류 ( 컴파일 오류, 런타임 오류 )

프로그램에서 오류는 컴파일 오류와 런타임 오류로 나눌 수 있다.


자바에서의 컴파일 오류

 

컴파일 오류는 소스코드를 .class 파일을 컴파일하는 과정에서 JVM이 던지는 오류이며

대부분 소스코드 자체의 문법적 오류로 인해 발생하는 경우가 대부분이고 프로그램 자체에서 처리할 수 있는 방법은 없다.

 

 

자바에서의 런타임 오류

 

런타임 오류는 문법적인 오류가 없어 컴파일 시에는 정상적으로 컴파일 되었으나

프로그램을 실행하는 과정에서 발생하는 오류를 의미하며, 오류 발생시 개발자가 직접 오류를 확인하여 처리해야 한다.

 

 


자바의신 참고

참고 : https://drsggg.tistory.com/671 (정리중이라 비공개 상태)

 

# 자바에서의 오류 ( java.lang.Exception 클래스 )

자바에서 모든 오류처리(컴파일 오류, 런타임 오류)는 에외(Exception)로 정의되고

모든 예외의 부모 클래스는 java.lang.Exception 클래스이다.

예외의 종류는 3가지이며, 2)와 3)을 제외한 모든 예외가 1)에 해당한다.
 1) Checked Exception
 2) Error
 3) Runtime Exception ( Unchecked Exception )

대부분 에러(Error)는 프로세스에 영향을 주고, 예외(Exception)은 쓰레드에 영향을 준다.



# Checked Exception

 

개발자가 직접 예측하여 막거나(예외처리) 혹은 복구 가능한 범주의 오류를 의미한다.

오류 여부를 컴파일(Compile) 시점에 확인하여 컴파일 오류를 발생시키므로, 반드시 예외처리(try-catch, throw)를 해야한다.

ex) ClassNotFoundException, IllegalAccessException, NoSuchMethodException


 

# Error

 

자바 프로그램 밖에서 발생한 예외를 의미하며, 프로그램이 코드로 복구될 수 없는 심각한 오류를 의미한다.

자바 프로세스에 영향을 주는 예외이며, 실행시 발생한다.

ex) 메모리 부족(OutOfMemoryError), 스택오버플로우(StackOverflowError), 서버의 디스크/메인보드 고장, 

 

 

# Runtime Exception (Unchecked Exception)

 

Runtime Exception은 Exception의 일종이지만, 명시적으로 예외처리를 하지 않아도 되기 때문에 이를 특별하게 취급한다. 

오류 여부를 런타임(Runtime) 시점에 확인하여 런타임 오류를 발생시키므로, 예외처리(try-catch, throw)가 없어도 컴파일에는 문제가 없지만 실행시 문제가 발생 할 수 있다.

ex) NullPointerException, ArithmeticException, IndexOutOfBoundsException



# Exception의 예외처리 (Checked Exception, Runtime Exception)

Exception은 Error와 다르게 개발자가 예외처리가 가능하다. (try-catch)

Exception은 Error와 다르게 개발자가 임의로 예외를 던질 수 있다. (throw)

 


# try-catch 예외처리


정상과 에러처리 코드 분리가 가능하여 코드가 간결해진다.

try-catch 블록을 메서드로 추출하면, 각 메서드는 정상/에러 처리에 집중 가능하다. (함수에 한가지 역할만 부여)

 


# throw 예외처리


예외처리 회피 전략이 될 수 있으며,

CustomException 을 만들어 throws 할 경우 예외 전환 전략이 될 수 있다.



# 자바에서의 에러 핸들링 ( 선처리, 후처리 에러 핸들링 )

에러 핸들링이란 에러가 발생하는 것에 대한 처리를 의미하므로, 선처리와 후처리 에러 핸들링으로 나눌 수 있다.

후처리 에러 핸들링은 다시 예외 복구, 예외처리 회피, 예외 전환 방법 등으로 나눌 수 있다.


 

# 선처리 에러 핸들링 (if문 분기처리 등)


선처리는 if문 분기처리를 이용한 null체크 등을 통해 에러 발생 전에 대비하는 것이다.

 


# 후처리 에러 핸들링 (리턴코드(Return Code), 익셉션(Exception : try-catch, throws) )


후처리는 리턴코드(Return Code), try-catch, throws 등의 예외처리를 통해 에러 발생 후를 대비하는 것이다.

후처리 에러 핸들링은 다시 예외 복구, 예외처리 회피, 예외 전환 방법 등으로 나눌 수 있다.

 


토비의스프링 4장 참고

참고 : https://drsggg.tistory.com/624

 

토비의스프링3.1 4장. 예외

토비의스프링 4장. 예외 난감한 예외처리 - 모든 예외는 적절하게 처리되던지 프로그램을 중단하여야 한다. 예외의 종류와 특징 - Error - 복구 불가능한 시스템 레벨의 문제이므로, catch로 잡아서

drsggg.tistory.com

 

 

# 예외 복구 방법


예외 복구는 예외 상황을 파악하고 문제를 해결하여 정상 상태로 돌려놓는 방법이다.

ex) 파일을 읽으려고 시도했으나 파일이 없어 IOException이 발생한 경우, 사용자에게 다른 파일을 이용하도록 안내하기

 

 

 

# 예외처리 회피 방법


예외 회피는 예외 처리를 직접 담당하지 않고 호출한 메서드로 위임해 회피하는 방법이다.

어떤 오브젝트가 어떤 예외를 다루어야 하는지 명확한 설계를 기반으로 확실한 의도로 수행하여야 한다.


 

# 예외 전환 방법


예외 회피와 유사하게 예외 처리를 직접 담당하지 않고 호출한 메서드로 위임하지만, 

그냥 위임하지 않고 적절한 예외로 전환해서 넘기는 방법이다.

내부에서 발생한 예외가 의미를 잘 표현하지 못 하는 경우, 조금 더 명확한 의미 전달을 위한 예외로 변경한다.

ex) 아이디가 중복된 경우 SQLException이 발생하지만, 이게 접속이 불가능한 상황인지 다른 상황인지 알 방법이 없다. 
이때 DuplicateUserIdException을 throw 해줄 경우, 중복된 아이디가 문제라는것을 상위 컨텍스트에서 알 수 있다.



클린코드 7장 참고

참고 : https://drsggg.tistory.com/750

 

에러 핸들링 비교 (Return OR throw Exception)

* 해당 글은 계속 수정 예정입니다. 최초 작성일 2023.04 마지막 수정일 2023.04 # 에러 핸들링 비교 리턴코드(Return Code) VS 익셉션(Exception : try-catch, throws) # 익셉션 (Exception : try-catch, throws) 장점 - 자바

drsggg.tistory.com

 

# 에러 핸들링 비교

리턴코드(Return Code) VS 익셉션(Exception : try-catch, throws)


 

# 익셉션(Exception : try-catch, throws)


장점
- 자바에서는 익셉션 사용을 권장하고 있다.
- try-catch 문의 사용으로 정상과 에러처리 코드 분리 가능하여 코드가 간결해진다.
- 런타임 예외의 보편화를 통해 개발자가 작성해야(신경써야) 할 부분을 줄일 수 있다.
- try-catch 블록을 메서드로 추출하면, 각 메서드는 정상/에러 처리에 집중 가능하다. (함수에 한가지 역할만 부여)

단점
- 스택트레이스가 길어진다.
- 컨텍스트(상태)를 가지지 않기에, 성공과 실패로만 구분이되어 세부적인 처리가 어렵다.
- 함수형에서 익셉션은 사이드 이펙트이고, 이는 순수함수를 깨는 것이다.


 

# 리턴코드(Return Code)


장점
- 하위 컨텍스트가 상태를 가지므로 오류를 명시적으로 처리 가능하다.
- 도메인을 중심으로 설계하기 편리하게 작용 할 수 있다.
  ex) 오류코드의 앞자리만 구분하여도 정합성/내부/DB/외부API 오류 등을 식별가능
- 익셉션이 발생하지 않으므로 함수형으로 볼 때 순수함수를 유지 할 수 있다.

단점
- 리턴코드를 따로 설계 및 관리해주어야 한다.
- 상위 컨텍스트에서 리턴코드에 대한 분기문과 관련로직이 늘어나게 되고 정상과 에러처리 로직이 섞여 코드의 간결성을 해칠 수 있다.
- 개발자가 작성해야(신경써야) 할 부분이 늘어날 수 있다.
- 프레임워크에서 제공하는 일부 기능을 활용하지 못할 수 있으며, 마찬가지로 프레임워크에 오류를 위임하지 못할 수 있다.
  ex) 스프링AOP가 제공하는 @Transaction




반응형
Comments