Rust 오류 처리에 빠진 한 조각

Rust 오류 처리에서 정확한 오류 타입과 간편한 전파를 양립하려면, 함수처럼 오류 타입도 쉽게 조합하고 처리한 오류는 타입에서 제거할 수 있어야 함 eros는 가능한 오류를 튜플 형태의 집합으로 표현하며, 새 enum이나 변환 코드를 선언하지 않고도 오류 집합을 합칠 수 있음 recover 는 처리한 오류 타입을 반환 오류 집합에서 제거함. 모든 오류를 처리하면 컴파일 시점에 오류가 남지 않았음을 확인하고 값을 꺼낼 수 있음 호출자가 오류 종류에 따라 복구해야 하는 경계에서는 타입을 유지하고, 단순히 전파하는 경계에서는 AnyError 로 단순화할 수 있으며 문맥과 백트레이스도 유지됨 오류 타입은 복구 정책을 결정하고 작업 문맥은 실패한 경로와 작업을 알려줌. eros는 기존 Result와 ?를 유지하면서 두 정보를 함께 전달함 기존 오류 타입을 조합할 때의 마찰 Rust는 이미 명시적 제어 흐름, 값으로 다루는 오류, ?를 통한 간결한 전파를 지원함. 어려움은 Result의 오류 쪽에 어떤 타입을 넣을지 결정할 때 생김 파일에서 서버 포트를 읽는 함수는 io::Error 와 ParseIntError 를 반환할 수 있음 일반적으로 PortError enum에 Io와 Parse 변형을 선언함 thiserror는 Display, Error, From의 수동 구현을 없애지만, 이 enum과 다른 오류 enum의 관계까지 해결하지는 않음 호스트 주소 읽기, 소켓 바인딩, 데이터베이스 초기화까지 조합하면 오류 enum 설계의 부담이 커짐 기존 enum을 새 enum으로 감싸면 중첩이 생김 변형을 새 enum에 평탄화하면 변환 코드가 필요함 크레이트 전체에서 하나의 큰 오류 타입을 쓰면 함수가 실제로 반환할 수 없는 오류까지 시그니처에 포함됨 같은 I/O 오류가 서로 다른 중첩 변형에 들어가면 상위 계층에서 처리하기 번거로움 anyhow 같은 방식은 오류 전파와 문맥 추가를 간단하게 하고, 구체적 오류를 확인할 때 다운캐스트할 수 있음 다만 함수 시그니처에서 가능한 오류 타입을 알 수 없고, 컴파일러도 모든 오류를 처리했는지 추적할 수 없음 라이브러리에는 타입이 있는 오류, 애플리케이션에는 불투명한 오류를 쓰라는 구분만으로는 충분하지 않음 애플리케이션도 타입별 복구가 필요하고, 라이브러리 내부에도 실패를 전파하기만 하면 되는 호출이 있음 실질적인 기준은 호출자가 오류 타입에 따라 다른 동작을 해야 하는지임 eros의 오...