Rust 오류 처리, 단순 전달은 이제 그만! 3AM에도 문제 해결 가능?
Rust 기반 시스템에서 오류 처리의 중요성을 강조하며, 기존 방식의 문제점을 지적함
std::error::Error 트레이트의 한계와 백트레이스의 비효율성을 분석하고, OpenDAL의 오류 설계 방식을 제시함
커뮤니티에서는 오류 컨텍스트 추가의 중요성에 공감하며, YAGNI 원칙 위반에 대한 반론도 제기됨
오류 처리 설계의 핵심 원리
오류 처리는 단순히 오류를 전달하는 것이 아닌, 오류의 목적을 명확히 정의하는 데서 시작한다. 구체적으로, 기계(Machine)가 자동 복구를 위해 필요한 정보를 제공하고, 사람(Human)이 디버깅을 위해 충분한 컨텍스트를 얻을 수 있도록 설계해야 한다. 따라서, OpenDAL과 같이 오류 종류(ErrorKind)를 기반으로 하고, ErrorStatus를 명시적으로 정의하는 접근 방식은 자동화된 복구와 디버깅 모두에 유용하다.
기존 방식의 문제점과 대안
기존의 std::error::Error 트레이트는 단일 원인(source)만을 지원하여, 복합적인 오류 상황을 제대로 표현하지 못한다. 반면, 백트레이스는 성능 저하를 유발하며, 비동기 코드에서 정확한 정보를 제공하지 못하는 경우가 많다. 따라서, exn 라이브러리와 같이 자동 위치 캡처 및 간편한 컨텍스트 추가를 지원하는 방식을 통해, 오류 발생 지점과 관련된 정보를 쉽게 파악할 수 있도록 해야 한다.
실제 시스템 적용 가이드
실제 시스템에서는 기계 친화적인 오류와 사람 친화적인 오류를 모두 고려해야 한다. 구체적으로, OpenDAL과 같이 구조화된 오류(flat struct)를 사용하고, exn과 같은 컨텍스트 추적 메커니즘을 결합하여, 각 계층에서 오류에 대한 컨텍스트를 추가해야 한다. 결과적으로, 자동화된 복구와 효율적인 디버깅을 동시에 달성할 수 있으며, 3AM에도 문제 해결이 가능해진다.
