개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
오류처리로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.
오류코드보다 예외를 사용하라.
예외의 의미를 제공해라.
TIL (Today I Learned) 날짜
2024. 02. 06
오늘 읽은 범위
7장. 오류 처리
책에서 기억하고 싶은 내용을 써보세요.
오류처리로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.
오류코드보다 예외를 사용하라.
예외가 발생할 코드를 짤때는 try-catch-finally
문으로 시작하는 편이 낫다. → try문에서 어떤 일이 생기던지 상태를 정의하기 쉬워진다.
try-catch 구조로 범위를 정의하고 TDD를 사용해 필요한 나머지 논리를 추가한다.
오류 메시지에 정보를 담아 예외와 함께 던지고 로깅 기능을 함께 사용한다면 오류를 찾기 위한 정보로 매우 유용하게 사용 가능
오류가 발생한 위치(컴포넌트)로 분류가 가능하다
외부 API를 사용할 때는 감싸기 기법이 최선이다. → 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.
특수사례 패턴 - 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식
을 사용하면 클래스나 객체가 예외적인 상황을 이미 캡슐화해서 처리하므로 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.
null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠 넘긴다.
null을 반환하는 순간 null 확인으로 코드는 망가질 것이다.
메서드에서 null을 반환하고픈 유혹이 든다면, 대신 예외를 던기거나 특수사례 객체를 반환한다.
사용하는 외부 API에서 null을 반환한다면 감싸기 매세드를 구현행 예외를 던기거나 특수 사례 객체를 반환하는 방식으로 코드는 보다 깨끗해 질 수 있다. → 공감, 공감!!!
null을 반환하는 방식보다 전달하는 방식이 더 나쁘다.
null을 전달하는 순간 함수내 NullPointerException 처리 코드로 인해 코드는 지저분해진다. 뿐만 아니라 실행 오류 발생 확률도 높아진다.
오류 처리 코드와 프로그램 논리를 분리해 보다 읽기 좋고 깨끗한 코드가 완성되며 유지보수성도 크게 높아진다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
오류처리로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 는 말에 가장 와 닿았다.
그 동안 작성한 코드는 다소 지저분한 코드였다는 반성을 하게 된다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
감싸기 기법을 통한 예외 정의 케이스의 사례를 좀 더 보고 싶다.
미확(unchecked) 예외를 사용하라는 무슨 의미일까?
오늘 읽은 다른사람의 TIL
frontend16님의 TIL (url 링크)