Errors are composable so this isn't such a problem in practice. Most of the prod code I wrote would do something like this
use thiserror::Error;
#[derive(Error, Debug)]
enum Error {
#[error("Could not open given decomp file: {0}")]
FileOpen(#[from] std:io::Error),
#[error("Compressed read error: {0}")]
CompressedRead(#[from] gz::Error)
}
fn decomp(filename: &Path) -> Result<Vec<u8>, Error> {
let fd = File::open(filename)?; // File is automatically closed by its destructor.
let zd = GzDecoder::new(fd); // flate2::read::GzDecoder::new does not return an error.
let mut data = Vec::new(); // Rust makes the caller allocate the buffer for reads.
zd.read_to_end(&mut data)?;
Ok(data)
}
Huh, can you explain that a bit more for a rust noob like myself?
1. How does it know how to create your Error enum? I guess it's from the #[from]?
2. What happens if your method tries to return something that's not an io::Error or a gz::Error? I guess the compiler catches that?
3. How would you handle doing this for multiple methods in the same file? Would you rename your enum to DecompError or something to avoid conflicts?
> How does it know how to create your Error enum? I guess it's from the #[from]? 2.
#[from] is just a convenience library feature, in reality it’s because of the From conversion trait which ? invokes on the way out. Essentially it calls ReturnType::from(ValueType) to bridge the two.
> What happens if your method tries to return something that's not an io::Error or a gz::Error? I guess the compiler catches that?
If there is no available conversion to the return error type, compilation fails.
> How would you handle doing this for multiple methods in the same file? Would you rename your enum to DecompError or something to avoid conflicts?
That is an option, although the slightly sad truth is libraries usually have a single big error type and every function returns that.
Convenient fine grained errors in rust remains unsolved, as far as I know. You can do it but it’s a lot of manual work.
