[7장] 오류 처리

[aronalee]

요약

• 오류코드보다는 예외를 사용해라. 오류코드의 유지보수가 어렵기 때문이다.
• try-catch-finaly부터 먼저 만들면 tx범위부터 개발을 할 수 있다.
• checked exception을 지양하고 unchecked exception을 사용해라. OCP규칙을 위반하여 캡슐화가 깨지기 때문이다.
• exception에 의미를 알 수 있는 전후사정에 대한 정보를 넣어라.
• exception은 호출자를 고려하여 작성해라. 호출자가 처리하기 쉽게 wrapper class로 내부에서 처리해주는 오류를
• null를 반환하지 않거나 전달하지 않으면 깨끗한 코드와 안정성이 높은 코드를 둘 다 가져갈 수 있다.
• 읽기 좋은 코드와 안정성이 높은 코드는 상충하지 않는다.

---

생각

'호출자를 고려해 예외클래스를 정의하라'는 챕터를 자세히 읽어봤다. 당장 고민하고 있던 사항이었기 때문이다. 예외 클래스를 어떻게 작성하고 이를 처리시켜줘야 좋은 코드가 될 지를 고민하고 있었는데 마침 이 챕터에서 고민을 해결할 수 있게되어 1장에서 강조하는 내용인 클린코드를 직접 적용해보는 시간이 되었다. 그리고 null에 대해 부정적인 묘사가 있는걸보니 null-safety한 kotlin이 뜨는 이유를 알 것 같다.

[chj990707]

• 오류보다는 예외를 사용하라
• try-catch-finally를 먼저 작성하라
• 확인된 예외는 캡슐화를 깨트린다.
• 예외 자체에 상황 설명을 충분히 제공하라.
• 호출자를 고려해서 예외를 작성하라.
• null 반환을 피하면 깨끗하고 안정적인 코드를 짤 수 있다.

생각

깨끗한 코드가 안정성도 높다는 내용이 중요하다고 생각한다. 어떤 함수가 null을 반환할지 알지 못하는 상황에서 마구잡이로 null 확인 코드를 추가한 적이 있기 때문에 null을 피하면 안정적이고 깨끗하다는 내용에 동의할 수 있었다.

[Roddyd94]

방법

예외 사용 try-catch-finally문 사용 미확인 예외 사용 예외에 의미 제공 호출자를 고려한 예외 클래스 정의: 외부 API에 Wrapper 클래스 사용 특수 사례 패턴 사용 null 반환 금지 null 인수로 사용 금지

요점

오류 처리와 로직 분리

생각

외부 API를 사용할 때 오류 처리를 어떻게 해야 하는지 의문이었는데 이 의문이 해소된 것 같다. 오류 처리는 내가 사용한 API에서 던지는 것만 보고 로직을 수정하는 방향으로만 작업을 했었는데, 내가 오류 처리를 해야 하는 상황이 어떤 경우가 있을 지에 대해 조금 더 생각해보게 되었다. 오류 처리에 관한 것도 깊이 파서 공부해보고 싶다.