뭔가 잘못될 가능성은 늘 존재하며, 잘못되는 것을 바로 잡을 책임을 프로그래머에게 있다. - p.130
흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 불가능해서는 안된다. - p.130
오류 코드보다 예외를 사용하라 : 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법은 잊어버리기 쉽기에 오류 처리가 발생하면 예외를 던지는 편이 낫다. - p.130
Try-Catch-Finally 문부터 작성하라 : 어떤 면에서 try 블록은 트랜잭션과 비슷하다. try블럭에서 무슨 일이 생기든 catch블록은 프로그램 상태를 일관성 있게 유지해야 한다. 예외가 발생할 코드는 try-catch-finally문으로 시작하는게 낫다. - p.132
강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법이 좋다. 자연스럽게 try블록의 트랜잭션 범위부터 구현하게 됨으로 범위 내에서 트랜잭션의 본질을 유지하기 쉬워진다. - p.133
미확인 예외를 사용하라 : 확인된 예외는 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다. 최하위 단계에서 최상위 단계까지 연쇄적인 수정이 일어나며 캡슐화가 깨진다. - p.133
예외에 의미를 제공하라 : 예외를 던질 떄는 전후 상황을 충분히 덧붙여야 원인과 위치를 찾기 쉽다. 오류 메세지에 정보를 담아 예외로 함께 던지며, 실패한 연산 이름과 실패 유형도 언급한다. 로깅 기능을 사용한다면 catch블록에서 오류를 기록하도록 충분한 정보를 넘겨준다. - p.135
호출자를 고려해 예외 클래스를 정의하라 : 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어드는데 이를 감싸기 기법이라고 한다. 감싸기 기법을 사용하면 특정 업체가 API를 설계한 방식에 발못잡하지 않는다. 한 예외는 잡아내고 다른 예외는 무시해도 괜찮은 경우라면 여러 예외 클래스를 사용한다. - p.135
정상 흐름을 정의하라 : 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식을 특수 사례 패턴이라고 한다. 특수 사례 패턴은 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어지게 한다. - p.137
null을 반환하지 마라 : null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘기게 된다. null을 반환하고 싶은 유혹이 든다면 예외를 던지거나 특수 사례 객체를 반환하는 것이 좋다. 사용하려는 외부 API가 null을 반환하다면 감싸기 메스드를 구현해 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려해야 한다. - p.138
null을 전달하지 마라 : 메서드로 null을 전달하는 방식은 더 나쁘다. 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇기에 null이 넘어오면 코드에 문제가 있다. -p.140
결론 : 깨끗한 코드는 읽기도 좋아야 하지만 안전성도 높아야 한다. 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다.
📝오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
예외처리를 try-except만 사용해보고 try-except-finally을 배운지 얼마되지않아서 처리에 익숙하지 않았는데 예외처리가 깨끗한 코드를 만들 수 있는 하나의 요소라고 생각하니 신기했다.
회사 선배님이 코드는 위에서 아래로 읽혀야하며, 시처럼 아름다워야 한다고 하셨는데 클린코드의 내용들이 떠올랐다. 모든 코드에 의미를 생각해서 작성한다면 언젠가 시처럼 아름다운 코드를 작성할 수 있지 않을까라는 바램이 생겼다.🥰
🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
OCP :
개방-폐쇄 원칙이라고 불리며, 소프트웨어 객체는 확장에 대해서 열려있어야 하고 수정(변경)에 대해서는 닫혀있어야 한다는 의미
