📅 TIL (Today I Learned): 2024.02.07
📋 오늘 읽은 범위: 7. 오류 처리
😎 책에서 기억하고 싶은 내용을 써보세요.
깨끗한 코드와 오류 처리는 확실히 연관성이 있다.
오류 코드보다 예외를 사용하라
예전에는 예외 처리를 지원하지 않아 어떤 함수 실행 후 오류 코드를 반환했다.
-> 이렇게 했더니 함수를 호출한 즉시 오류를 확인해야 했다.
-> 코드가 더러워진다.
그래서 오류가 발생하면 예외를 던지는 편이 낫다.
-> 논리와 오류 처리 코드가 뒤섞이지 않아 코드가 깔끔해진다.
Try-Catch-Finally 문부터 작성하라
어떤 면에서 try 블록을 트랜잭션과 비슷하다. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
-> 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉽게 'try-catch-finally' 문으로 시작하는 편이 낫다.
먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 법을 권장한다. (TDD)
-> 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다.
미확인 예외를 사용하라. (unchecked)
https://slow-and-steady-wins-the-race.tistory.com/103
(미확인 예외를 이해하기 위해 찾아봄)
최상위 함수가 아래 함수를 호출하는 방식에서 단계를 내려갈수록 호출하는 함수 수는 늘어난다. 최하위 함수를 변경해 새로운 오류를 던진다고 가정하면, 함수는 선언부에 throws 절을 추가해야 한다.
-> 연쇄적인 수정이 일어난다.
-> 모든 함수가 최하위 함수에서 던지는 예외를 알아야 한다.
RuntimeException 사용하라는 뜻으로 느껴진다.
예외에 의미를 제공하라.
예외를 던질 때는 전후 상황을 충분히 덧붙인다.
오류 메시지에 정보를 담아 예외와 함게 던진다. (실패한 연산 이름, 실패 유형)
null을 반환하지 마라.
null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다.
null 체크하는 코드도 늘어나 코드를 해친다.
null을 반환할 필요가 없는 코드를 만들면 된다.
null을 전달하지 마라.
대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇다면 애초에 null을 넘기지 못 하도록 금지하는 정책이 합리적이다.
결론
깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다.
🥺 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
(매번 맥으로 적다가 윈도우로 적으니까 이 이모지가 이렇게 못생겼는지 이제 처음 알았다... 당황스럽다...)
프로젝트 진행 중 예외 처리를 해야 할 때마다 항상 try-catch문에 대한 이상한 반발심 때문에 사용하기가 어렵게 느껴진다. 내가 여기서 이걸 감싸도 되나 싶고, 여기서만 예외처리를 하면 개발 규칙에 어긋날까봐 걱정도 되기 때문이다.
한 번 읽는다고 예외 처리를 하는 게 익숙해지진 않는다... 효율적으로 예외처리를 할 수 있는 방법은 따로 고민을 해봐야겠다.
🤔 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
'호출자를 고려해 예외 클래스를 정리하라'라는 부분은 쉽게 와닿지 않았다.
외부 라이브러리를 감싸서 이용했을 때 어떤 부분에서 크게 이점이 있는지...
공부법 공유하기~
실제로 이렇게 진행 중인데 어떻게든 뭐가 완성되어가고 있긴 하다.
