본문으로 건너뛰기
피드

에러의 두 가지 종류

backend 약 3분
vote
0
댓글
북마크

소프트웨어 에러를 expected(정상 운영 중 발생, 처리 필요)와 unexpected(버그, crash 허용)로 나누는 프레임워크를 제안하는 글. 맥락에 따라 선 긋는 위치가 달라지며, Rust의 에러 철학과 맥이 같음.

  • 1

    Expected error는 throw/panic 대신 Result 타입 등으로 반환하고, WARN/INFO 로그 사용

  • 2

    Unexpected error는 버그를 의미하므로 crash/panic 허용, ERROR/FATAL 로그 사용

  • 3

    프로토타입이면 대부분 unexpected, 미션 크리티컬이면 대부분 expected로 분류

  • 4

    Rust/Zig는 엄격하게, JS/Python은 느슨하게 에러를 분류하는 경향

  • Evan Hahn의 블로그 글로, 소프트웨어 에러를 딱 두 종류로 나눠서 생각하자는 제안임
  • 예상 가능한 에러(Expected errors): 유효성 검증 실패, 네트워크 장애, 권한 부족 같은 것들. 정상 운영 중에 당연히 발생할 수 있고, 개발자 잘못이 아님. Result 타입이나 null 유니온 같은 걸로 반환해서 처리해야 하고, throw/panic은 하면 안 됨. 로그 레벨은 WARN이나 INFO가 적절
  • 예상 못한 에러(Unexpected errors): assertion 위반, 로직 에러, 잘못된 데이터 같은 것들. 이건 버그라는 뜻이므로 crash/panic 해도 됨. 오히려 프로그램을 완전히 뻗게 만드는 게 장기적으로 더 안정적인 소프트웨어를 만든다는 입장. 로그는 ERROR/FATAL 레벨로
  • 어디에 선을 긋느냐는 맥락에 따라 다름. 프로토타입이면 모든 에러가 unexpected이고, 50년짜리 우주 탐사선이면 거의 모든 에러가 expected임. 실무에서는 신뢰성을 높일수록 expected로 분류하는 범위가 점점 넓어지게 됨
  • 언어별 철학도 다른데, Rust나 Zig 같은 엄격한 언어는 더 많은 에러를 expected로 취급하고, JavaScript나 Python은 unexpected 쪽으로 빠지는 경향이 있음. 본인은 프로덕션엔 엄격한 언어, 스크립트엔 느슨한 언어를 선호한다고
  • 결국 Rust의 에러 처리 철학(Result vs panic)과 거의 같은 이야기인데, 언어 불문하고 적용할 수 있는 사고 프레임워크로 정리한 거임

새로운 이야기는 아니지만, 언어 불문하고 에러 처리 전략을 정리하는 깔끔한 멘탈 모델. 특히 주니어 개발자에게 유용한 프레임워크임.

댓글

댓글

댓글을 불러오는 중...

backend

잘못된 추상화보다 중복이 낫다는 샌디 메츠의 고전 조언

샌디 메츠는 중복을 없애려다 잘못된 추상화를 만들면 코드가 조건문과 파라미터로 부풀어 더 위험해진다고 말한다. 이미 틀어진 추상화는 억지로 보존하지 말고, 다시 호출부에 인라인해서 중복을 되살린 뒤 현재 요구사항에 맞는 새 구조를 찾는 편이 빠르다는 주장이다.

backend

리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

리눅스 커널이 오랫동안 버그의 원인이던 strncpy API 사용을 Linux 7.2에서 제거했어. NUL 종료 동작이 직관적이지 않고 불필요한 zero-fill로 성능 문제도 있던 API를 6년 동안 약 362개 커밋으로 걷어낸 작업임.

backend

덕디비는 왜 빠를까: 서버 없는 분석 엔진의 내부 구조 뜯어보기

DuckDB가 단일 바이너리, 인프로세스 실행, 컬럼형 저장, 최적화 패스, Parquet 푸시다운으로 빠른 분석 쿼리를 처리하는 방식을 깊게 설명한 글이다. 6GB Parquet 파일을 노트북에서 바로 SQL로 읽는 경험 뒤에 어떤 설계가 깔려 있는지 따라간다.

backend

피지독, 포스트그레스를 수평 확장시키겠다고 550만 달러 투자 유치

피지독은 포스트그레스 앞단에 프록시를 두고 샤딩과 라우팅을 처리해 수평 확장을 가능하게 하겠다는 오픈소스 프로젝트다. 이미 프로덕션에서 초당 200만 건이 넘는 쿼리를 처리하고, 확인된 규모만 20테라바이트 이상을 샤딩했다고 밝히며 550만 달러 투자를 공개했다.

backend

펜타시스템, EDB 포스트그레SQL로 국내 엔터프라이즈 DB 전환 시장 공략

펜타시스템테크놀러지가 EDB와 파트너 계약을 맺고 국내에 EDB 포스트그레SQL 기반 데이터 플랫폼을 공급한다. 기존 상용 DBMS 정책 변화로 비용 부담이 커진 기업들을 겨냥해, 오픈소스 기반 엔터프라이즈 데이터 플랫폼 전환 수요를 잡겠다는 전략이다. 금융, 공공, 제조, 유통, 클라우드, AI 데이터 분석 환경까지 적용 범위를 넓히려는 움직임이다.