TIL (Today I Learned)

2022.03.01

오늘 읽은 범위

7. 오류 처리

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

1. 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. - p130

2. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. - p130

3. 그래서 오류가 발생하면 예외를 던지는 편이 낫다. 그러면 호출자 코드가 더 깔끔해진다. 논리가 오류 처리 코드와 뒤섞이지 않으니까. - p131

4. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. (중략) 그러면 try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다. - p132

5. 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. - p133

6. 그러므로 우리는 확인된 오류가 치르는 비용에 상응하는 이익을 제공하는지 (철저히) 따져봐야 한다. (중략) 확인된 예외는 OCP를 위반한다. - p134

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

8. 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식이다. 그러면 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다. - p138

9. null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. (중략) 메서드에 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. - p139-140

10. 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 이 둘은 상충하는 목표가 아니다. - p142

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

역시 Kent Beck과 함께 애자일 소프트웨어 개발 (Agile software development)를 외친 저자다. 이 장에서 약간이나마 저자의 TDD 철학을 엿볼 수 있었다. 한국에서 TDD는 비교적 최근에 핫해진 프로세스로 알고 있는데, 이 책이 처음 발간된 당시에는 신문물이었으리라.

나는 "오류 처리"보다는 "예외 처리"가 더 적절하다고 생각한다. 프로그래밍에서 대부분의 (사실상 모든) Error는 Human error다. 이 장에서 언급했듯이 null이 전달된다거나, 정말 간단하게는 index가 넘어간다거나. 이 오류들에 대한 책임은 전적으로 개발자에게 있다. 예외 처리를 염두에 두고 아주 작은 단위로 애플리케이션을 구성한다면 웬만해서는 오류가 발생하지 않는다.

언뜻 생각하면, 예외 처리와 클린 코드 사이의 연결이 희미해 보인다. 하지만 여기저기서 떠넘긴 예외가 덕지덕지 붙은 코드를 보고 있자면..., 확실히 연관성이 있어 보인다! 이 장에서 언급된 대로, 중구난방의 예외 처리 코드는 논리의 흐름을 방해한다. 또한, 이 책에서 말하는 클린 코드는 단순히 보기에만 깔끔한 코드가 아니다. 깨끗이 돌아가는, 보기에도 깔끔한 코드다.

나 또한 예외 처리를 위한 try / catch, try / except, tryCatch() 등을 주로 사용한다. try문은 예외를 처리할 수도 있게 만들어주지만, 일단 코드가 작동하게 만들어 준다. 흐름을 끊지 않고도 나에게 놓친 예외를 확인시켜준다. 하지만 나도 종종 null을 반환하고 null 예외를 처리하도록 코드를 작성하는데, 이 부분은 고쳐야겠다.