How to deal with errors that don't implement the Error trait?

[yanshay]

I'm new to Snafu, and did several standard tests to get the hang of it and managed to use it.
I need to use it though, in no_std and alloc so errors there may not be defined as standard as on std.
I'm using main branch where alloc was introduced recently.

I'm using a library where the Error is an enum that only has derive Debug (also generic over another error, but I don't think it's relevant here).

Let's say it is:

#[derive(Debug)]
enum LibError {
    FirstError,
    SecondError,
}

I want to have my own error type defined in my code that uses that library.

#[derive(Debug, Snafu)]
enum CallerError {
    MyErrorError {
        source: LibError
    },
}

The definition above errros with:

error[E0599]: the method `as_error_source` exists for reference `&LibError`, but its trait bounds were not satisfied
  --> src/main.rs:18:17
   |
18 | #[derive(Debug, Snafu)]
   |                 ^^^^^ method cannot be called on `&LibError` due to unsatisfied trait bounds
...
26 | enum LibError {
   | ------------- doesn't satisfy `LibError: AsErrorSource` or `LibError: snafu::Error`
   |
   = note: the following trait bounds were not satisfied:
           `LibError: snafu::Error`
           which is required by `LibError: AsErrorSource`
           `&LibError: snafu::Error`
           which is required by `&LibError: AsErrorSource`
note: the trait `snafu::Error` must be implemented

If I replace LibError with some standard Error, ParseIntError for example it work. So it's probably due to the LibError not implementing Error trait.

I tried using #[snafu(source(from(...)))] thinking it may help, but couldn't get it to work, tried to use String instead of LibError in the source and also do from with a function that converts the LibError to String. Couldn't get anything working. Went through the docs and discussions and couldn't find a solution.

So I'm trying to figure out what's the correct way to use Snafu under such library error type.

[shepmaster]

So it's probably due to the LibError not implementing Error trait.

Yes, that's correct. That's what the following trait bounds were not satisfied: `LibError: snafu::Error` is attempting to say (the snafu:: prefix is an artifact of some implementation details, that's the same as core::error::Error).

Unfortunately, this isn't anything particularly special about no_std — SNAFU expects to deal with types that participate in the shared Error abstraction. What is special about no_std is that core::error::Error is relatively new (Rust 1.81.0), so many libraries that are no_std couldn't use it (and still may not, depending on their MSRV).

The best thing to do is to poke the maintainers of LibError to implement core::error::Error (maybe they can use SNAFU to do so 😉).

In the meantime, you can write a little wrapper that implements Error and then use snafu(source(from(...))) to hook it in easier:

use core::fmt;
use snafu::prelude::*;

#[derive(Debug)]
enum LibError {
    FirstError,
    SecondError,
}

struct LibErrorWrap(LibError);

impl core::error::Error for LibErrorWrap {}

impl fmt::Debug for LibErrorWrap {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        self.0.fmt(f)
    }
}

impl fmt::Display for LibErrorWrap {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        fmt::Debug::fmt(&self.0, f)
    }
}

#[derive(Debug, Snafu)]
enum CallerError {
    MyErrorError {
        #[snafu(source(from(LibError, LibErrorWrap)))]
        source: LibErrorWrap,
    },
}

That will allow you to use it as usual:

fn myfn() -> Result<(), CallerError> {
    libfn().context(MySnafu)
}

[yanshay]

Thanks.

That would require poking many maintainers - probably tens of them I use since all had the same issues until recently, or implement many wrappers.

Out of interest, to just include the source error or even just a string representing the source error in a way that is simple for the user, does Snafu need the Error trait? Or is it just required to enforce the shared Error abstraction?
It seems like it could be possible to just support converting Debug to the string and allow including it as source, or even the original error itself.

[shepmaster]

That would require poking many maintainers - probably tens of them

Perhaps, but assuming that each maintainer has 2+ users, the total impact would be much greater for them to perform the change.

or implement many wrappers

Maybe? There's not really anything special about the wrapper I showed; you could likely make it generic and use it in a number of places, assuming that all the other errors also implement Debug as the common thing.

struct DebugWrap<E>(E);

impl<E: fmt::Debug> core::error::Error for DebugWrap<E> {}

impl<E: fmt::Debug> fmt::Debug for DebugWrap<E> {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        self.0.fmt(f)
    }
}

impl<E: fmt::Debug> fmt::Display for DebugWrap<E> {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        fmt::Debug::fmt(&self.0, f)
    }
}

#[derive(Debug, Snafu)]
enum CallerError {
    MyErrorError {
        #[snafu(source(from(LibError, DebugWrap)))]
        source: DebugWrap<LibError>,
    },
}

Out of interest, to just include the source error or even just a string representing the source error in a way that is simple for the user, does Snafu need the Error trait?

Yes / no. To include the error, you conceptually don't need anything. The problem is that then every error has to have a hand-crafted way to ask for the source (and its source, etc.) which means that the error type doesn't play well with anything else. That's the whole point of the Error trait.

Without that, you could also choose to write it as:

#[derive(Debug, Snafu)]
enum CallerError {
    MyErrorError {
        #[snafu(source(false))]
        source: LibError,
    },
}

fn myfn() -> Result<(), CallerError> {
    libfn().map_err(|source| MySnafu { source }.build())
}

With this version, asking CallerError for its Error::source will return None, but it's still included inside the CallerError.

It seems like it could be possible to just support converting Debug to the string and allow including it as source, or even the original error itself.

My personal preference (doubly so in restricted environments like embedded) is to avoid treating errors as strings. SNAFU mostly includes Whatever and friends to help people get some error handling on the way towards having strongly typed errors.

That being said, you could probably do the same wrapping idea as above with a string:

#[derive(Debug, Snafu)]
enum CallerError {
    MyErrorError {
        #[snafu(source(from(LibError, DebugError::absorb)))]
        source: DebugError,
    },
}

struct DebugError(String);

impl DebugError {
    fn absorb(other: impl fmt::Debug) -> Self { Self(format!("{other:?}")) }
}

impl core::error::Error for DebugError {}

impl fmt::Debug for DebugError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        self.0.fmt(f)
    }
}

impl fmt::Display for DebugError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        fmt::Debug::fmt(&self.0, f)
    }
}

[yanshay]

Awesome answer! Thanks

[yanshay]

Ok, I was able to use the above to deal with my error using context.

Now I'm looking for how to use Snafu under the same constraints with errors not implementing Error trait, for the simple case when I don't need source, and want an ergonomic error handling. use of context seem to enforce source and the added overhead above.

I just want to create an Error enum, and then have the error from the underlying library to automatically convert to my Error enum, by me specifying the type of error the underlying library error should be converted to. Is it possible with snafu, or do I need to be explicit?
I'm not sure this question relates to lack of implementing core::Error, but it might be so keeping it here.

I found the following options below: one doesn't seem very ergonomic (ensure!) to me, one is bypassing Snafu and not the most ergonomic either (map_err), two other options I'd assume would be possible don't seem to be supported:

#[derive(Snafu, Debug)]
pub enum Error {
    #[snafu(display("Too many store operations pending"))]
    TooManyOps
}

impl Store {
    pub fn try_submit_op(&self, op: StoreOp) -> Result<(), Error> {
        let res = self.requests_channel.try_send(op);
        ensure!(res.is_err(), TooManyOpsSnafu);    // <---- Snafu, doesn't feel very convenient to use
        res.map_err(|_| Error::TooManyOps)?;       // Doesn't take advantage of Snafu
//      res?;                                      // <---- This is how I would want it to work in this case, but it doesn't
//      res.context(TooManyOpsSnafu)?;             // <--- or even this would be nicer/easier than the first two, but requires source
        Ok(())
    }
}

[shepmaster]

No, not really. The whole point of SNAFU is to make it so that you keep all your error information. You are fighting against this because your libraries aren't returning what the Rust ecosystem considers errors (that is, they don't implement the Error trait).

What I do when I don't care about the error detail, just if it was an error or not, is to convert from the Result to an Option:

#[derive(Snafu, Debug)]
enum Error {
    MyClassification,
}

fn makes_error() -> Result<(), ()> {
    Ok(())
}

fn uses_error() -> Result<(), Error> {
    makes_error().ok().context(MyClassificationSnafu)
}

If you really wanted to get the question mark operator to work, you could implement From yourself such that it discards the source:

#[derive(Snafu, Debug)]
enum Error {
    MyClassification,
}

impl From<()> for Error {
    fn from(_value: ()) -> Self {
        Self::MyClassification
    }
}

fn makes_error() -> Result<(), ()> {
    Ok(())
}

fn uses_error() -> Result<(), Error> {
    makes_error()?;
    Ok(())
}