Rethink error types #25
Comments
asomers
added a commit
to asomers/capsicum-rs
that referenced
this issue
Dec 19, 2022
CapErr simply served to wrap an io::Error around an enum that mainly just served to tell the user what function he had just called. But the user already knew that. Simpler just to return io::Error directly. The only complication was Directory::open_file, which needs to handle a NulError. I mapped that to io::Error with an ErrorKind of Other. Fixes dlrobertson#25
asomers
added a commit
to asomers/capsicum-rs
that referenced
this issue
Dec 19, 2022
CapErr simply served to wrap an io::Error around an enum that mainly just served to tell the user what function he had just called. But the user already knew that. Simpler just to return io::Error directly. The only complication was Directory::open_file, which needs to handle a NulError. I mapped that to io::Error with an ErrorKind of Other. Fixes dlrobertson#25
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I find
CapErrto be confusing. Every type wraps eitherio::Errororffi::NulError. The variants mainly serve to tell the user which function returned the error. But the user already knows that. I propose that we use plainio::Resultfor all functions whose inner error type is anio::Error. And for the few functions with more complicated error types we'll make an enum for each one. That's essentially the approach we take in the Nix crate.The text was updated successfully, but these errors were encountered: