errorcon 0.1.0

A small crate for scoping errors and easier error conversion
Documentation
  • Coverage
  • 0%
    0 out of 8 items documented0 out of 5 items with examples
  • Size
  • Source code size: 5.53 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 1.23 MB This is the summed size of all files generated by rustdoc for all configured targets
  • Links
  • Homepage
  • tesseract-one/Tesseract.rs
    9 3 0
  • crates.io
  • Dependencies
  • Versions
  • Owners
  • dileping

Error Context

Sometimes implementing a trait one has to return a specific error, while the code inside can return multiple various errors.

The problem becomes even more annoying when all the errors are defined in crates, that are not in control of the user and thus no From and nice looking ?.

Application level error

One of the sulutions is to create an app-level Error, that implements From for all the errors the app needs to deal with, and Into for the nasty trait function error (see above in the description).

Still one has to constantly use map_err in the code.

ErrorContext is to eliminate map_err

trait ApiToImplement {
    fn important_fn() -> Result<String, ApiError>;
}

impl ApiToImplement for MyStruct {
    fn important_fn() -> Result<String, ApiError> {
        MyAppError::context(|| {
            method1()?;
            method2()?;
            Ok(method3())
        })
    }
}

Considering that method1, method2, method3 all return different errors, the above looks much cleaner, then explicitely converting errors for each call:

method1().map_err(|e| /*conversion*/)?;
method2().map_err(|e| /*conversion*/)?;
method3().map_err(|e| /*conversion*/)

Licence

Apache 2.0