TIL (Today I Learned)

// 2022.03.03

오늘 읽은 범위

// 7장. 오류 처리

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

• 오류 처리는 프로그램에 반드시 필요한 요소 중 하나일 뿐이다. 입력이 이상하거나 디바이스가 실패할지도 모르기 때문이다. 간단히 말해, 뭔가 잘못될 가능성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다. -130p

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

• 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. -133p

• 확인된 예외는 OCP를 위반한다. 메서드에서 확인된 예외를 던졌는데 catch 블록이 세 단계 위에 있다면 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다. 즉, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다는 말이다. -134p

• 예외를 던질 때는 전후 상황을 충분히 덧붙인다. 그러면 오류가 발생한 원인과 위치를 찾기가 쉬워진다. - 135p

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

• 실제로 외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다. 나중에 다른 라이브러리로 갈아타도 비용이 적다. - 137p

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

• 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다. - 142p

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

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

• 저자가 말한 것처럼, 깨끗한 코드는 가독성, 안정성 모두를 추구해야 하며, 이 두 특성은 연결되어 있다고 생각한다. 오류 처리 코드를 작성하는 대신, 예외를 던짐으로써 함수는 본래의 목적에 더욱 충실할 수 있으며, 유지보수 측면에서도 더욱 편리하다. 또한, null을 자주 사용하게 되면, null을 실수로 넘겨줌으로써 발생하는 문제를 해결하기 힘들어질 것이고, 의미도 더 전달하기 어렵다. 이는 가독성과 안정성 측면 모두에서 옳지 않다. 이처럼, 두 측면은 연결되어 있으며, 그렇기 때문에 프로그래머는 두 측면 모두 향상시킬 수 있도록 노력해야 한다.

• 과거에 코딩을 하면서, 오류 코드를 작성해 함수 안에 넣어놓거나, 오류가 발생하는 경우를 피하기 위해 null을 자주 사용했던 때가 떠올랐다. 이렇게 생각 없는 행동으로 인해 나의 협업자와 미래의 나를 얼마나 힘들게 했을까하는 생각이 들었다. 이번 챕터에서 배웠던 내용을 잘 숙지해서 다시는 같은 실수를 반복하지 않기 위해 노력해야겠다.

• 클린코드 책을 읽으면 읽을수록, 객체 지향 프로그래밍에 대한 지식의 부족이 발목을 더욱 잡아끄는 것 같다고 느꼈다. 그래서 사놓았던 객체 지향 프로그래밍 언어인 자바와 관련된 책을 읽으면서 클린코드를 읽으며 헷갈렸던 내용들을 다시 쳐다보고 있다. 이해되지 않는 것들을 내버려두지 말자. 더 노력하자!

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

• 클라이언트 코드 -> 클라이언트 코드는 호출하는 함수, 서버 코드는 호출되는 함수 (참고 : https://opentutorials.org/course/668)

• 특수사례패턴 (Special Case Pattern) : 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식. 이렇게 클래스나 객체가 특수 사례를 캡슐화해서 처리하게 되면, /*클라이언트 코드*/가 직접 예외를 처리할 필요가 없어진다. 책에서 언급한 대로, null 처리 함수를 이용함으로써 null을 자주 사용하는 것을 막을 수 있을 것 같다. (참고 : https://harrislee.tistory.com/63)

• Checked exception / Unchecked exception -> 확인된 예외 / 비확인된 예외를 RuntimeException을 상속하지 않는지, 상속하는지를 기준으로 나누고, 이에 따라 반드시 명시되어야 하는지, 아니면 그러지 않아도 되는지를 기준으로 나누는 것으로 보인다. 결국, 핵심은 OCP를 준수할 수 있도록, 무책임하게 상위 클래스로 throw를 하지 말아라는 것 같은데, rollback과 같은 개념은 잘 이해가 가지 않고, 책에서 언급된 부분도 읽을수록 아리송하다. 참고 링크를 보고 좀 더 이해해봐야겠다. (참고1 : https://madplay.github.io/post/java-checked-unchecked-exceptions, 참고2 : https://cheese10yun.github.io/checked-exception/)