Rust 에러 처리를 다루면서 라이브러리용 에러 타입을 깔끔하게 정의하는 thiserror는 살펴봤는데요. 정작 그 단짝인 anyhow는 아직 다루지 않았습니다. 둘은 보통 한 쌍으로 거론되지만 역할이 정반대거든요. 애플리케이션 코드를 짜다 보면 함수 하나에서 파일도 읽고, 문자열도 파싱하고, 네트워크도 호출합니다. 그러면 std::io::Error, ParseIntError 등 종류가 다른 에러가 마구 쏟아지는데요. 이걸 일일이 enum으로 묶어 정의하는 건 과합니다. 어차피 최종적으로는 "어디서 왜 실패했는지" 로그를 남기고 프
자바스크립트로 파일을 읽거나 파이썬으로 API를 호출해본 경험이 있으시다면, 아마 try/catch나 try/except로 예외를 잡는 방식이 익숙하실 겁니다. 그런데 Rust 코드를 처음 보면 이상한 점이 눈에 들어옵니다. 분명히 파일을 여는데 try도 없고, 함수 시그니처에 throws도 없고, 대신 Result<T, E>라는 낯선 타입이 반환됩니다. 🤔 이번 글에서는 다른 언어와 비교했을 때 Rust 에러 처리가 가지는 가장 특이한 지점들과, 일상적인 실패와 버그를 Rust가 어떻게 갈라놓는지를 정리해보겠습니다. 예외가 아니
Rust의 에러 처리에서 봤듯이, Rust는 실패 가능성을 Result<T, E> 타입으로 반환 타입에 박아 넣는 언어입니다. 다만 매번 match로 풀어내기엔 코드가 너무 장황해지죠. 그래서 표준 라이브러리는 Result를 다루는 다양한 메서드를 갖춰두고 있습니다. 이번 글에서는 실무에서 자주 만나는 Result 메서드를 용도별로 정리해보겠습니다. 조기 반환에 쓰는 ? 연산자부터, 에러를 변환하는 map_err, 값을 갈아 끼우는 map/and_then, 그리고 회복용 unwrap_or 패밀리까지 한 번에 살펴봅시다. Result
Rust는 명시적이고 안전한 오류 처리를 중시하는 프로그래밍 언어입니다. 대표적으로 Result 타입과 ? 연산자를 통해 다양한 에러 상황을 타입 시스템으로 포착할 수 있죠. 하지만 실무에서 직접 오류 자료형을 정의하고 Error 트레이트를 구현하다 보면, 반복적인 보일러플레이트 코드 작성에 지치는 경우가 많습니다. 이럴 때 thiserror 라이브러리가 여러분의 구세주가 될 수 있습니다. Error 트레이트 우선 표준 라이브러리의 Error 트레이트를 직접 구현하는데 필요한 최소한의 코드를 보여드리겠습니다. 아래 Validatio
GraphQL 서버에서 클라이언트로 부터 요청받은 쿼리(Query)나 뮤테이션(Mutation)을 실행하다가 오류가 발생할 수 있습니다. 이런 경우, GraphQL 서버에서 해당 오류에 대한 정보를 응답해줘야 클라이언트에서도 그에 상응하는 화면 처리를 할 수가 있을 것입니다. 이번 포스팅에서는 Apollo Server로 개발된 GraphQL 서버에서 어떻게 오류 처리를 해야하는지 알아보도록 하겠습니다. 오류 발생 시 응답 결과 GraphQL 서버에서 오류가 발생할 경우, Apollo Server는 HTTP 응답 바디의 errors