TIL (2022.02.04)

DAY 14

🔖 오늘 읽은 범위 : 7장, 오류 처리 (복습)

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

스케쥴을 착각해 저번에 7장을 읽을 때, 전부 다 읽어 버렸다!
오늘은 7장을 다시 읽어보면서 중요하다 생각하는 내용들만 다시 적어보려고 한다.

• 클린 코드에서 오류 처리를 언급하는 이유!
  • 오류 처리는 중요하다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.
• 오류 코드보다 예외를 사용하라
  • 함수를 호출한 즉시 오류를 확인하면, 호출자 코드가 더러워지고 이런 오류를 처리해야 한다는 것을 잊어버리기 쉽다.
  • 예외를 사용하면 논리가 오류 코드와 뒤섞이지 않아 호출자 코드가 더 깔끔해진다.
• Try-Catch-Finally 문부터 작성하라
  • try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
  • 그러면 try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다. → 프로그램의 논리가 오류를 처리하면서 끊기는 게 아니라, 기존의 흐름(=기대하는 상태)를 유지할 수 있다. 이로 인해 코드의 가독성은 더 증가한다.
    
• 미확인 예외를 사용하라
  • 하지만 지금은 안정적인 소프트웨어를 제작하는 요소로 확인된 예외가 반드시 필요하지는 않다는 사실이 분명해졌다.
    • 처음에 읽었을 때 이해가 안되었는데, 두 번째 읽어보니 이 문장이 핵심이었던 것 같다. 확인된 예외는 어떻게 보면 잘못된 요청인 것 같다. 잘못된 요청에 대해 모두 대응할 시간에, 프로그램의 논리 상 잘못된 부분을 찾는 것이 더 의미 있는 작업이라는 것을 말하는 것 같다.
• 호출자를 고려해 예외 클래스를 정의하라
  • 하지만 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.
  • 예외를 단순히 나열하기보다는 감싸기 기법(Wrapper 클래스 생성) 등을 이용하면 호출자에 의존적이지 않게 오류 처리를 할 수 있다. 특히 외부 API를 사용하는 경우는 감싸기 기법이 최선이다.
• 정상 흐름을 정의하라
  • 모든 오류를 다 예외로 처리하려는 생각은 좋지 못하다. 특수 사례 패턴(SPECIAL CASE PATTERN)과 클래스를 만들거나 객체를 조작해서 프로세스 흐름을 유지하는 것이 더 좋을 때도 있다.
• null을 반환하지 마라. null을 전달하지 마라 → NullpointerException, InvalidArgumentException
  • null은 호출자에게 실수를 일으키게 한다!
  • null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.
  • 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다.
• 결론: 클린 코드를 위한 오류 처리 방법은?
  • 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지 보수성도 크게 높아진다.

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

• 스케쥴을 착각해서 얼떨결에 같은 파트를 두 번 읽게 되었다. 두 번째 읽으니 잘 이해되지 않았던 미확인 예외에 관련해서 조금은 더 이해할 수 있게 되었다. 그리고, 오류 처리는 때에 따라 프로그램의 흐름을 방해할 수도, 더 잘 이해할 수 있게 만들 수도 있다고 느꼈다.

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

• 없음

소감 3줄 요약

• 오류 처리는 때에 따라 프로그램의 흐름을 방해할 수도, 더 잘 이해할 수 있게 만들 수도 있다.
• 예외 클래스가 그 역할(프로그램을 더 잘 이해하게 도움)을 해줄 수 있다.
• 외부의 잘못된 요청보다는 내부의 논리적 오류에 집중하자.