오늘도 삽질중

오류처리와 예외처리가 다른건가? 본문

기타

오류처리와 예외처리가 다른건가?

Choi3950 2020. 11. 27. 11:49
반응형

본 포스팅은 개인정리 목적으로 작성된 글입니다.

잘못된 정보가 있을 수 있으며, 피드백은 겸허히 받겠습니다.




클린아키텍처 오류처리 챕터를 읽으며 문득 이런생각이 들었다.

흔히 개발할때 "예외처리 어떻게 했어요?" 란 질문을 받거나 해본적이 있지만

"오류(에러)처리 어떻게 했어요?" 라는 말은 해본적도 없고 들어본적이 없었다.

막연하게 보면 둘다 비슷한 뜻을 가지고 있다고 생각을 했지만

막상 찾아보니 다른 내용이 많았다.

이번글은 여러 블로그를 찾아보며 해당 내용에 대한 정리와 개인적인 생각을 첨언했다.



오류(에러) 와 예외의 차이점?


오류(에러) :  시스템에 비정상적인 상황이 생겼을 때 발생한다.

즉 시스템 레벨에서 발생하기 때문에 심각한 수준의 오류이며, 개발자가 예측하여 처리할 수 없다.

ex) Out Of Memory Excetion  , SatckOverFlow Excetion


예외 : 개발자가 구현한 로직에서 발생한다.

예외가 발생할 가능성을 개발자가 미리 예측하여 처리할 수 있다.

ex)  NullPointExcetion , FormatExcetion



***

오류(에러)는 시스템 레벨에서 발생하고

예외는 개발자가 구현한 로직에서 발생한다.

***


오류(에러) 처리

- 시스템 레벨에서 발생하는 에러를 처리한다.


예외 처리

- 개발자가 코드를 작성할 때 부주의함으로 인해 발생되는 에러를 처리한다.

- 프로그램 실행시 예측가능한 에러를 예측하고 처리하여 비정상 종료를 방지하고 실행상태를 유지한다.


즉 개발자 입장에선 시스템에서 발생하는 오류는 처리할 수 없는거 같고,

예외처리만 가능하다는게 나의 결론이다.


예외클래스 상속도


모든 Exception, Error 클래스는 Throwable을 상속받고 있다.

흔히 앱 실행중에 자주보게 되는 RuntimException은 Excetion을 상속하고 있다.

그래서 흔히 Try Catch 문을 사용할 때 Catch 문에 Excetion을 선언하면 모든 에러를 캐치할 수 있어서 의아했는데 해당 그림을 보고 한번에 이해가 되었다.

try{
//실행코드
}catch (e : Exception){
e.printStackTrace()
}



Checked Exception ? Unchecked Exception ?

해당 표만 봐도 둘의 차이점을 명확히 알 수 있다.


표에 나오지는 않았지만 Checked Exception중에서 JSONException 을 살펴봤다.

Java에선 JsonObject만 선언하게 되면 컴파일단계에서 에러가 발생한다.

여담으로 신기했던게 Kotlin에선 선언해도 에러가 안났다.

아무튼 Java 에선 이렇게 빨간줄로 에러가 발생한다.


그래서 보통 Try Catch 로 감싸서 이렇게 사용한다.

try{
JSONObject jsonObject = new JSONObject(json);
//....
//....
}catch (JSONException e){

}


Catch에 들어가는 JSONException의 내부 코드는 아래와 같다.

public class JSONException extends Exception {

public JSONException(String s) {
super(s);
}

public JSONException(String message, Throwable cause) {
super(message, cause);
}

public JSONException(Throwable cause) {
super(cause);
}

}


잘보면 Exception을 상속하고 있으므로 JSONException 은 Checked Exception에 해당된다.

즉 컴파일단계부터 에러가 발생하여 반드시 처리를 해줘야 한다.


다음은 NullPotionException을 살펴봤다.

public
class NullPointerException extends RuntimeException {
private static final long serialVersionUID = 5162710183389028792L;

/**
* Constructs a {@code NullPointerException} with no detail message.
*/
public NullPointerException() {
super();
}

/**
* Constructs a {@code NullPointerException} with the specified
* detail message.
*
* @param s the detail message.
*/
public NullPointerException(String s) {
super(s);
}
}


NullPointException은 RunTimeException을 상속하고 있다.

즉 Unchecked Exception에 해당된다.

처리를 강제하지 않으므로 개발자가 구현할 때 주의를 해야한다.




되도록 Try Cacth 를 사용하는게 좋다?


클린코드 책의 한 부분으로 Try Cacth의 적절한 사용예시를 만들어봤다.

사용자의 집주소를 입력받아 집주소에 지역코드를 넣는다는 시나리오가 있다고 가정한다.

public String attachAreaCode(String homeAddress) {
if (homeAddress != null) {
return AREA_CODE + homeAddress;
}
return AddressEmpty;
}

homeAddress 가 null 인지 확인하고 값을 리턴한다.

해당코드는 조건이 하나뿐이라 깔끔해 보이지만 

만약 null 체크외에 자릿수나 정규식등 여러가지 조건이 들어가게 되면 ??

if 안에 if문이 중첩으로 들어가게 된다.

이렇게 되면 개발자가 실수를 할 확률도 높아지고 가독성이 좋지 않다.

그러므로 클린코드 책에선 아래처럼 처리를 권장하고 있다.

public String attachAreaCode(String homeAddress) {
try {
return AREA_CODE + homeAddress;
} catch (NullPointerException e) {
return AddressEmpty;
}
}





예외처리의 대표적인 방법 3가지

1. 예외복구 : 다른 작업 흐름으로 유도한다. 핵심은 애플리케이션의 흐름은 유지된다.

2. 예외처리 회피 : 처리하지 않고 호출한 쪽으로 throw를 던진다.

3. 예외 전환 : 명확한 의미의 예외로 전환 후 throw


해당 내용을 가지고 직접 위의 시나리오 를 가정하여 간단한 예외처리 예제를 작성해봤다.


예외복구

public String attachAreaCode(String homeAddress) {
try {
return AREA_CODE + homeAddress;
} catch (NullPointerException e) {
return AddressEmpty;
}
}

예외가 발생하여도 애플리케이션의 흐름을 유지하도록 한다.



예외처리 회피

public String attachAreaCode(String homeAddress) throws NullPointerException {
return AREA_CODE + homeAddress;
}

예외가 발생하게 되면 throws를 통해 해당 함수를 호출한 쪽으로 예외를 던지고, 해당 함수는 처리를 회피한다.



예외전환

public String attachAreaCode(String homeAddress) {
try {
return AREA_CODE + homeAddress;
} catch (NullPointerException e) {
throw new AddressEmpty("Address is Empty Error");
}
}

예외가 발생하게 되면 명확하게 인지할 수 있도록 처리한다.



* 해당글과 클린아키텍처 책을 보신분들은 의아한 점이 있을겁니다.

클린아키텍처 챕터에 오류처리가 있는데 이 블로그에서 말한 '오류'랑 의미가 좀 다른거 같다.

아마 클린코드책에 있는 '오류' 라는 단어는 제 블로그에서 말하는 '예외' 라는 뜻으로 이해하시는게 좋다고 생각합니다.



반응형
Comments