1.0.25

• Add no-std support (#53)

  In no_std mode, the same API is almost all available and works the same way. To depend on Anyhow in no_std mode, disable our default enabled "std" feature in Cargo.toml. A global allocator is required.

  [dependencies]
  anyhow = { version = "1.0", default-features = false }

  Since the ?-based error conversions would normally rely on the std::error::Error trait which is only available through std, no_std mode will require an explicit .map_err(Error::msg) when working with a non-Anyhow error type inside a function that returns Anyhow's error type.

1.0.24

• Preserve cause chain when converting from Box<dyn StdError + Send + Sync> to anyhow::Error (#50)
• Work around bug in NixOS package infrastructure (#49)

1.0.23

• Add impl AsRef<dyn std::error::Error> and impl AsRef<dyn std::error::Error + Send + Sync> for anyhow::Error
• Add Chain::new constructor

1.0.22

• Preserve cause chain when bail! or ensure! is invoked with anyhow::Error as the error argument (#46)

1.0.21

• Provide DoubleEndedIterator and ExactSizeIterator implementations for anyhow::Chain to assist in custom rendering of cause chains (#45)

  let chain = err.chain();
  if chain.len() > 1 {
      eprint!("[[root cause]] ");
  }
  for err in chain.rev() {
      eprintln!("{}", err);
  }

1.0.20

• Introduce some {:#} and {:#?} alt formatting representations (#42)

  When you print an error object using "{}" or to_string(), only the outermost underlying error or context is printed, not any of the lower level causes. This is exactly as if you had called the Display impl of the error from which you constructed your anyhow::Error.

  Failed to read instrs from ./path/to/instrs.json

  To print causes as well using anyhow's default formatting of causes, use the alternate selector "{:#}".

  Failed to read instrs from ./path/to/instrs.json: No such file or directory (os error 2)

  The Debug format "{:?}" includes your backtrace if one was captured. Note that this is the representation you get by default if you return an error from fn main instead of printing it explicitly yourself.

  Error: Failed to read instrs from ./path/to/instrs.json
  
  Caused by:
      No such file or directory (os error 2)
  
  Stack backtrace:
     0: <E as anyhow::context::ext::StdError>::ext_context
               at /git/anyhow/src/backtrace.rs:26
     1: core::result::Result<T,E>::map_err
               at /git/rustc/src/libcore/result.rs:596
     2: anyhow::context::<impl anyhow::Context<T,E> for core::result::Result<T,E>>::with_context
               at /git/anyhow/src/context.rs:58
     3: testing::main
               at src/main.rs:5
     4: std::rt::lang_start
               at /git/rustc/src/libstd/rt.rs:61
     5: main
     6: __libc_start_main
     7: _start

  To see a conventional struct-style Debug representation, use "{:#?}".

  Error {
      context: "Failed to read instrs from ./path/to/instrs.json",
      source: Os {
          code: 2,
          kind: NotFound,
          message: "No such file or directory",
      },
  }

  If none of the built-in representations are appropriate and you would prefer to render the error and its cause chain yourself, it can be done something like this:

  use anyhow::{Context, Result};
  
  fn main() {
      if let Err(err) = try_main() {
          eprintln!("ERROR: {}", err);
          err.chain().skip(1).for_each(|cause| eprintln!("because: {}", cause));
          std::process::exit(1);
      }
  }
  
  fn try_main() -> Result<()> {
      ...
  }

1.0.19

• Export anyhow! also under the alias format_err! (#37)

1.0.18

• Support downcasting errors with context to the context's type C or to the underlying error type E (#34)

  That is, in codebases that rely on downcasting, Anyhow's context now supports both of the following use cases:

  • Attaching context whose type is insignificant onto errors whose type is used in downcasts.

    In other error libraries whose context is not designed this way, it can be risky to introduce context to existing code because new context might break existing working downcasts. In Anyhow, any downcast that worked before adding context will continue to work after you add a context, so you should freely add human-readable context to errors wherever it would be helpful.

    use anyhow::{Context, Result};
    
    fn do_it() -> Result<()> {
        helper().context("failed to complete the work")?;
        ...
    }
    
    fn main() {
        let err = do_it().unwrap_err();
        if let Some(e) = err.downcast_ref::<SuspiciousError>() {
            // If helper() returned SuspiciousError, this downcast will
            // correctly succeed even with the context in between.
        }
    }

  • Attaching context whose type is used in downcasts onto errors whose type is insignificant.

    Some codebases prefer to use machine-readable context to categorize lower level errors in a way that will be actionable to higher levels of the application.

    use anyhow::{Context, Result};
    
    fn do_it() -> Result<()> {
        helper().context(HelperFailed)?;
        ...
    }
    
    fn main() {
        let err = do_it().unwrap_err();
        if let Some(e) = err.downcast_ref::<HelperFailed>() {
            // If helper failed, this downcast will succeed because
            // HelperFailed is the context that has been attached to
            // that error.
        }
    }

1.0.17

• Work around poor paths in compiler diagnostic when missing Context import (#30)

1.0.16

• Add impl From<anyhow::Error> for Box<dyn std::error::Error + 'static> (#25)