Skip to content

Latest commit

 

History

History
81 lines (62 loc) · 6.87 KB

Ch7.md

File metadata and controls

81 lines (62 loc) · 6.87 KB
Raw

Ch 07. Error Handling

생각 공유

@ChanhuiSeok

단순히 try-catch-finally를 넘어서 오류 처리와 관련한 패턴과 OCP와 같은 것들을 새롭게 알 수 있던 장이었다.

  • 오류가 발생하면 예외를 던지는 편이 낫다. ✏ JavaScript에도 throw 를 하는 문법이 존재한다.
  • try-catch-finally 문부터 작성하라. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
  • unchecked 예외를 사용하라 ✏ 자바에는 checked exception과 unchecked exception이 있다. 여기서는 하위 단계에서 checked 예외를 처리하지 않고 throw 했을 때, 모든 상위 코드의 메서드 선언부를 고쳐야 하므로 기존 구성요소의 수정이 계속해서 요구되기 때문에 OCP(Open Closed Principle)를 위반한다고 말하고 있다. 그래서 unchecked exception 사용을 권장한다.
  • 예외에 의미를 제공하라 → 오류 메시지에는 충분한 정보를 담아서 예외와 함께 던지자.
  • 호출자를 고려해 예외 클래스를 정의하라 ✏ 책에는 예시로 외부 라이브러리를 호출하는 경우가 나온다. 그 라이브러리에서 던질 예외를 일일히 모두 잡지 않고, 이것을 감싸는 클래스를 만들고 예외 유형 하나만 반환하게끔 해서 처리하면, 모든 예외에 대해 catch 하지 않아도 된다는 것이다.
  • 특수 사례 패턴 ✏ 이 예시는 코드 흐름에 있어서 예외 처리가 논리 흐름을 따라가기 어렵게 하지 말자는 의미로 제시한 예시라고 생각햇다.
  • null을 반환하거나 전달하는 습관 -> null은 계속 null인지 아닌지 확인을 해야 해서 코드의 일거리도 늘리고, 호출자에게 문제를 떠넘긴다고 이야기한다. ✏ JavaScript의 경우, 없음을 표현하는 값이 null과 undefined 를 일일히 if문으로 체크하여 코드가 길어지는 것을 방지하고자 옵셔널 체이닝, null 병합 연산자(??, nullish coalescing operator) 등을 제공하고 있다. 하지만 이들 모두 주의해서 사용해야 하는 점은 변함이 없다. 옵셔널 체이닝의 경우 정말 옵셔널해도 괜찮은 부분에만 써야 한다.

@jjangsungwon

기억에 남은 문구

  • 오류가 발생하면 예외를 던지는 편이 낫다. 그러면 호출자 코드가 더 깔끔해진다. 논리가 오류 처리 코드와 뒤섞이지 않으니까
  • 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다.
    • 테스트 케이스를 작성할 때 정상 동작을 먼저 확인하였었다. 예외를 일으키는 테스트 케이스를 먼저 작성하는 것도 좋은 방법이라고 생각한다.
  • 일반적인 애플리케이션은 의존성이라는 비용이 이익보다 크다.

로깅 기법

  • 로깅은 프로젝트 개발할 때 자주 사용하고 있다.
  • 파이썬은 로깅 레벨을 설정할 수 있다. (DEBUG, INFO, WARNING, ERROR, CRITICAL
    • DEBUG < INFO < WARNING < ERROR < CRITICAL 순서로 레벨이 높다.
    • 개발할 때는 DEBUG 레벨을 설정하여 수많은 정보를 확인하는 것이 편리하지만 배포 후에는 모든 DEBUG 레벨의 로그를 볼 필요가 없기 때문에 상황에 따라 레벨을 조절해서 사용하고 있다. (print 문 사용 거의 안함)

Null 반환

  • null 반환, null 전달 노노 ? 어쩔 수 없이 사용해야하는 경우도 있지 않을까?
    • 웹에서 '전체' 항목을 선택 -> sql query 에서는 필터링 할 필요가 없음. 하지만 전체라는 값이 넘어온 상황임 -> 전체를 null 로 변환해서 처리하고 있었음

감싸기 기법

  • 파이썬도 클래스, 객체 모두 개발 가능하지만 뭔가 자바에 비해서 확실히 덜 활용하는 것 같다.
  • 그래서 감싸기 기법도 이번에 책을 안 봤으면 영원히 생각하지 못한 기법일 것 같다(?)
  • 책에서 보여준 예제는 정말 좋았고 만약 내가 자바를 주언어로 했었다면 감탄했었을 것 같다.
  • 리액트 16부터는 Error Boundary라는 컴포넌트를 제공함으로써 에러를 효과적으로 처리할 수 있다고 하네요.
    • Error Boundary에서 포착되지 않은 에러들이 발생하게 되면 리액트 전체 검토넌트가 마운트 해제된다. 따라서, 컴포넌트 어느 부분에서 에러가 발생하더라도 화면의 모든 요소들이 렌터링되지 않는 현상이 일어난다고 하네요. 이는 손상된 UI는 렌더링되는 것보다 완전히 제거하는 것이 더 옳다고 판단한 것 같다고 합니다.

@qrlagusdn

오류 코드보다 예외를 사용하라

  • 오류 status 를 하나 하나 지정해서 하기보다는 예외를 사용하는 것이 맞음
  • try - catch 와 같이 전체적인 맥락에서 오류를 잡을 수 있음
    • try 문이 하나의 트랜잭션 역할을 한다.
    • catch 블록은 프로그램 상태를 일관성 있게 유지함

미확인 에외를 사용하라

  • 오류 코드를 싹 다 지정하는 것처럼 예외를 모두 확인된 예외로 사용할 수 있지만, 미확인 예외를 사용하는 것도 분명히 필요함
  • 확인된 예외는 OCP를 위반함
    • Open Closed Principle
      • 기능이 추가될 때 소프트웨어는 확장을 하고, 변경은 최소화하자
      • 시스템이 확장하기 쉬우면서 너무 많은 영향을 받지 않도록하기 위함
  • 함수를 호출하다보면 call stack depth 가 깊어질 수 밖에 없는데, 확인된 예외만 사용한다면 영향받는 함수가 너무 많아짐.
    • 우리 예시
      • CLI → SDK → API-server
        • API-Server
          • Layer 별로 추상화 수준을 다르게 해서 예외 종류를 나눴음 image
    • → 아래에서 나오는 예외 클래스 정의가 하나의 해결책이 될 수 있음 (감싸기 기법 == 래핑)

Null 반환 , Null 전달 노노!

회의록

  • 폴더 관리

    • 프로젝트 루트 경로에 회의록 폴더(summary) 라고 만들고, 그 밑에 주마다 논의했던 내용을 작성해서 올린다. (서로 공유한 내용, 회의록 포함)
    • repo에 내용을 올릴 때는 main에 바로 push 한다. (따로 branch, PR 관리 X)

  • issue 탭 사용

    • 구글밋 전에 한 주동안 스터디했던 장을 개인적으로 간단하게 정리해서 issue 탭에 올린다. (공유하고 싶은 내용이나 자료를 포함해도 괜찮다)
    • issue 탭에 올릴 때 타이틀은 [Ch1] 챕터 제목 이름 의 형태로 올린다.
    • 구글밋에서 각자 생각을 공유할 때 issue 탭에 작성한 것을 참고용으로 활용하면 좋겠다.