오늘 TIL 3줄 요약

• 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다.

• Try-Catch-Finally문은 오류처리에 최적의 방법이다.

• 오류 처리를 프로그램 논리와 분리 하면 독립적 추론이 가능해 코드 유지보수성도 크게 높아진다.

TIL (Today I Learned) 날짜

2022.03.05

오늘 읽은 범위

7장. 오류처리

책에서 기억하고 싶은 내용을 써보세요.

• 오류 코드보다 예외를 사용하라

• Try-Catch-Finally 문부터 작성하라

• 확인된 예외는 OCP Open Closed Principle1 를 위반한다.

• 메서드에서 확인된 예외를 던졌는데 catch 블록이 세 단계 위에 있다면 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다. 즉, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다는 말이다. 모듈과 관련된 코드가 전혀 바뀌지 않았더라도 (선언부가 바뀌었으므로) 모듈을 다시 빌드한 다음 배포해야 한다는 말이다.

• 때로는 확인된 예외도 유용하다. 아주 중요한 라이브러리를 작성한다면 모든 예외를 잡아야 한다. 하지만 일반적인 애플리케이션은 의존성이라는 비용이 이익보다 크다.

• 예외에 의미를 제공하라

• 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.

• 실제로 외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브 러리와 프로그램 사이에서 의존성이 크게 줄어든다. 나중에 다른 라이브러리로 갈아타도 비용이 적다. 또한 감싸기 클래스에서 외부 API를 호출하는 대신 테스트 코드를 넣어주는 방법으로 프로그램을 테스트하기도 쉬워진다.

• 흔히 예외 클래스가 하나만 있어도 충분한 코드가 많다. 예외 클래스에 포함된 정보로 오류를 구분해도 괜찮은 경우가 그렇다. 한 예외는 잡아내고 다른 예외는 무시해도 괜찮은 경우라면 여러 예외 클래스를 사용한다.

• null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 누구 하나라도 null 확인을 빼먹는다면 애플리케 이션이 통제 불능에 빠질지도 모른다.

• null을 전달하지 마라

• 메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은더 나쁘다. 정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null을 전달하는 코드는 최대한 피한다.

• 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적 이다. 즉, 인수로 null이 넘어오면 코드에 문제가 있다는 말이다. 이런 정책을 따르면 그만큼 부주의한 실수를 저지를 확률도 작아진다.

• 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 이 둘은 상충하는 목표가 아니다. 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다. 오류 처리를 프로그램 논리와 분리 하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

오류처리를 위한 코드 작성시 오류 작성을 위한 코드를 사용하는 것이 좋겠다.(if 등 사용 안할 것)

역시나 중복을 최소화 하는 것이 필요할 것이고, 단순화 시켜 읽기도 좋아야 할 것이다.

그렇게 생각을 해 보면, 복잡한 구조는 복잡한 처리를 거쳐 누가 봐도 복잡해 보인다.

복잡하게 구상 했다면 이후로는 단순화 시킨 후 코드 작성하는 습관이 좋은 습관일 것 같다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

OCP(Open Closed Principle)

• '소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다'는 프로그래밍 원칙이다.

• 시스템의 구조를 올바르게 재조직(리팩토링)하여 나중에 이와 같은 유형의 변경이 더 이상의 수정을 유발하지 않도록 하는 것이다.

• 개방-폐쇄 원칙이 잘 적용되면, 기능을 추가하거나 변경해야 할 때 이미 제대로 동작하고 있던 원래 코드를 변경하지 않아도, 기존의 코드에 새로운 코드를 추가함으로써 기능의 추가나 변경이 가능하다.

확장에 대해 열려 있다.

이것은 모듈의 동작을 확장할 수 있다는 것을 의미한다. 애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있다. 즉, 모듈이 하는 일을 변경할 수 있다.

수정에 대해 닫혀 있다

모듈의 소스 코드나 바이너리 코드를 수정하지 않아도 모듈의 기능을 확장하거나 변경할 수 있다. 그 모듈의 실행 가능한 바이너리 형태나 링크 가능한 라이브러리를 건드릴 필요가 없다.

추상화를 통한 개방-폐쇄 원칙

• 객체 지향 프로그래밍 언어에서는 고정되기는 해도 제한되지는 않은, 가능한 동작의 묶음을 표현하는 추상화가 가능하다.

• 모듈은 추상화를 조작할 수 있다. 이런 모듈은 고정된 추상화에 의존하기 때문에 수정에 대해 닫혀 있을 수 있고, 반대로 추상화의 새 파생 클래스를 만드는 것을 통해 확장도 가능하다.

• 따라서 추상화는 개방-폐쇄 원칙의 핵심 요소이다.

오늘 읽은 다른사람의 TIL

• wpvspv님의 TIL (https://nomadcoders.co/community/thread/3311)