[클린코드] 7장 오류처리

요새 클린코드를 다시 읽으면서 아래 노션링크에 독서록을 남기고 있다. 
https://organized-panama-944.notion.site/337d75ef13ff40d7bc33dbba40d30dc6?pvs=4
그 중 오류처리 부분을 읽으면서 필자는 왜 이렇게 하라는 걸까? 라고 생각하며, 내 언어로 이해한 것들을 남겨 보았다:)

  - 오류코드보다 예외를 사용하라고 하는 이유는 뭘까?  

: 오류발생시 확인하는 과정도 잊지 않고 검토 할수 있고, 실행로직과 오류처리 코드가 뒤섞이지 않고 분리되어 가독성 측면에서도 좋고, 실행로직을 재사용하기에도 좋아지기 때문

 

  - try-catch-finally문 작성을 권장하는 이유는 뭘까?  

: catch문이 실행된다면 try에 문제가 있을때이다. 그렇기 때문에 오류의 범위가 좀더 명확해지고, 이를 test보기도 편해진다.

 

  - 확인된 예외와 미확인 예외는 무슨차이일까?  

1. 확인된 예외란?
⇒ 일반적으로 개발자가 예측할 수 있는 상황에서 사용하는 것
⇒ 컴파일 시점에 예외처리를 강제함
⇒ 예외가 발생할 수 있는 메서드를 사용시에는 ‘예외처리 하는 코드를 작성’하거나, ‘해당 예외를 호출자에게 전달’해야 함
⇒ 이를 통해 프로그램 안정성을 높이는 데 목적이 있음

2. 미확인 예외란?
⇒ 주로 프로그램 버그, 프로그래밍 오류 상황같은 개발자가 예측불가능한 상황에 사용됨
⇒ 컴파일 시점에 예외를 강제 하지 않아, 주로 런타임에 발생함
⇒ 프로그램의 일반적 흐름을 방해하지 않으면서 개발자가 예외적 상황을 처리할 수 있도록 유연성 제공함

 

  - 왜 미확인 예외를 쓰라고 할까?  

: 확인된 예외란 어떤 행위가 잘못되었을 때 그것 하라고 부른 상부에 예외를 정의해야 한다. 그래서 하위단계에서 코드 변경하는 것으로 인해 다른 코드들도 고쳐야 하는 상황이 일어날 수 있어 “OCP: 확장에는 열려있고 수정엔 닫혀있어야 한다는” 법칙을 위반하게 된다.

그래서 확인된 예외는 정말 아주 중요한 라이브러리를 작성할때는 아주 아주 꼼꼼하게 모든 예외를 잡아야 하는 것에 유용하다.

하지만 모든 프로그램을 이렇게 작성시 비용이 어마어마 + 개발자의 흰머리증가 + 머리빠짐⇒ 탈모로 이어지기 때문에 미확인 예외를 적절히 사용한다면 유용하다는 것

 

  - 예외에 의미를 제공하라는 이유?  

: 사과 깍다가 문제가 생겨서 예외를 “문제1 발생”이라고 만 던진다면, 사과를 먹다가 문제 생긴건지, 사과를 들고있다가 문제 생긴건지 알수가 없다. catch문에서 정확히 오류를 기록할 수 있게 “ 사과 깎다가 문제 생김”이라고 예외를 던져야 사과 깍는 부분을 찾아보면서 원인, 위치 찾기 쉬워진다.

 

 - 호출자에 따라 예외클래스를 정의하라는 이유? 

: 오류가 발생한 위치로 분류할수 있기 때문! 짱구가 문제야. 라고 하는 것보다 짱구는 훈이가 불렀을때 문제야 하면 짱구가 어디서 문제를 일으키는지 빨리 찾을수 있기 때문

 

  - 정상흐름을 정의하라는 것의 팁일까?  

: 실행로직에 너무 많은 예외가 붙어있다보면, 혹은 클라이언트 코드에서 예외처리를 하려고 하면,
예외가 오히려 논리를 어지럽힐때가 있다.

이런 경우 일일히 예외를 나열해 붙이기보다,
특수 사례 패턴을 활용해서, 클래스나 객체가 '예외적 상황을 표현하는 객체'를 반환하도록 해서, 실행 로직에 붙어있는 예외를 지우고, 클라이언트 코드에서의 복잡한 예외를 줄이는 것이 좋다는 팁?!

 

  - null을 반환하지도, 전달하지도 말라는 이유는?  

: null을 반환하면 오류를 유발하는 행동이기 때문, 예기치 않은 Nullpointer exception의 원인이되기도하고, null을 일일히 체크하는 것도 힘들기 때문에 차라리 null 대신 예외던지기, 혹은 특수 사례 객체를 반환하는 방식을 고려하는 것이 좋다.

인수로 null이 넘어오면 함수의 side effect, 예외처리 등을 생각해야해서 차라리 Optional같은 기능을 사용한다면 값의 부재를 더 안전하고 선언적으로 표현할수 있다고 한다.