개발자 99% 커뮤니티에서 수다 떨어요!
[Day 13 of 21] 클린코드 TIL
오늘 TIL 3줄 요약
깨끗한 코드는 오류 처리가 깔끔해야한다.
깨끗한 코드는 읽기도 좋고 안정성도 높아야 한다.
오류 처리는 프로그램 논리와 분리해 독자적으로 고려해야 한다.
TIL (Today I Learned) 날짜
2024.02.07
오늘 읽은 범위
7장. 오류처리
책에서 기억하고 싶은 내용을 써보세요.
오류 처리는 중요하지만, 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부를 수 없다.
<깨끗한 코드를 위해 오류를 잘 처리하는 기법>
오류 코드보다 예외를 사용하기
오류 코드를 사용하면 호출자 코드가 복잡해지고 함수를 호출한 즉시 오류를 확인해야하는 번거로움이 있다. (심지어 이 단계는 잊기 쉽다) 대신 오류 발생 시 예외를 만들면 코드가 더 깔끔해진다.
Try-Catch-Finally 문부터 작성하라.
예외가 발생할 때 Try-Catch-Finally 문으로 시작하는 편이 낫다 -> try블록에서 무슨 일이 생기든 호출자가 기대하는 상태를 정의하기 쉬워지기 때문.
먼저 강제로 예외를 일으키는 테스트 케이스 작성 후 테스트를 통과하게 코드를 작성하는 방법 권장
미확인 (unchecked) 예외를 사용하라
확인된 예외도 중요하지만, 안정적인 소프트웨어를 제작하는 요소로는 확인된 예외가 반드시 필요하지는 않다.
예외에 의미를 제공하라
예외를 던질땐 전후 상황을 충분히 덧붙여라. 오류메시지에 정보를 담아 예외와 함께 던지기.
호출자를 고려해 예외 클래스를 정의하기
오류를 잡아내는 방법에 주목하기
정상 흐름을 정의하기
특수사례 패턴(Special case pattern: 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식 -> 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하기 때문에 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어짐.
null을 반환하지 말것
null을 반환하는 코드는 일거리를 늘리고 호출자에게 문제를 떠넘기는 방식이다.
null을 전달하지 말것
대다수 프로그램 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 따라서 애초에 null을 넘기지 못하도록 금지하는 게 합리적.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
전전 장에서 try, catch구문은 이쁘지 않다고 했는데, 갑자기 또 여기선 오류 코드보다 예외를 던지라고 해서 조금 혼란이 왔다. 이것도 결국엔 알잘딱깔센인건가…ㅠㅠ
먼저 강제로 예외를 일으키는 테스트 케이스 작성 후 테스트를 통과하게 코드를 작성하는 방법 권장 -> 이 부분 진짜 중요하고도 효과적인 코드 짜는 방법이라고 생각이 든다. 프로젝트를 할 때 프로그램을 만들면서 수많은 예외 케이스 때문에 통과되지 못하고 (다 했다고 생각할 때쯤 예외는 또 등장…하하) 좌절할때가 있었는데 이 부분을 보니 이런 방식이 참 효과적이었겠구나 하고 생각이 든다.
미확인 예외를 읽으면서 저 단어에 대한 개념이 잘 서지 않아 찾아보니 아래에 정리한 것 같은(궁금한 내용) 내용과 같았다. 미확인 예외를 사용하는 것에 중요성은 잘 알겠지만, 개발자의 실수, 예상치 못한 상황으로 발생하는 예외라면 미리 예측하는 게 가능한가? 뭔가 닭이 먼저냐 달걀이 먼저냐의 느낌이군. 그래서 좀 더 찾아봤더니, 내가 참 예외처리에 대해서 너무 사소하게 생각하고 있었구나 하는 생각이 들었다. 예외처리도 참 기법이 많고 이해해야할 게 많구나… (예외처리 관련해 찾아본 사이트 중 하나)
null을 반환하지 말라는 챕터 제목을 읽자마자 뜨끔했다. null을 자주 쓴 건 아니지만, 처음에 팀 과제를 할 때 한 번 리뷰에서 null사용을 자제해야한다고 들은 적이 있었다. 그 다음부턴 불가피한 상황이 아니면 최대한 다른 방향으로 코드를 짜려고 궁리해본다… 근데 null을 넘기는 경우의 코드도 있구나… 반환하는 게 아니라 인자로 넘기는 걸 말하는 것 같은데 한번도 본적이 없고 생각만해봐도 엄청 불안정할 것 같은데… 너무 당연한 소리 같음과 동시에 끔찍해 보였다.
오류 처리 중요하다고 생각은 했지만, 이번 챕터를 읽으면서 생각했던 그것보다 훨씬 더 심오하고 복잡하고 중요하다고 느꼈다. (사실 모든 챕터를 읽으면서 생각했던 것 이상으로 모든 부분이 생각했던 것보다 더더더 중요하다는 걸 매번 깨닫는 중…)
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
TDD(Test-driven development): 실제 코드를 작성하기 전에 테스트 작성에 중요성을 두는 소프트웨어 개발 방식.
확인된 예외(Checked Exception): 컴파일러가 강제로 처리하도록 하는 예외.
확인되지 않은 예외(Unchecked Exception): 개발자의 실수나 예상치 못한 상황 등으로 발생하는 예외.
오늘 읽은 다른사람의 TIL
charminggw님의 TIL: 중간 중간에 책에 있던 코드를 색깔을 입힌 코드로 한 번 더 정리해 올려주셔서 보기가 편했다. 아무래도 책은 흑백 코드로 돼 있어서 들여쓰기가 돼 있다 한들 눈에 확 인들어온다. 그리고 궁금한 내용에 찾아본 사이트들도 함께 정리해주셔서 더 읽어볼 거리가 있어 도움이 된 TIL!
두번째 과제 - 공부 방법 슬랙에 공유하기
