shepmaster / snafu

Easily assign underlying errors into domain-specific errors while adding context
https://docs.rs/snafu/
Apache License 2.0
1.39k stars 60 forks source link

Use the same deprecation macros on the no_std Error as the official Error #425

Closed NWPlayer123 closed 8 months ago

NWPlayer123 commented 9 months ago

While writing up documentation, I noticed several deprecation warnings concerning description and cause, which have been deprecated since March 2020 and February 2019 respectively, which are coming up on 4 and 5 years ago, so I think it's high time to remove them entirely. Any repositories that still rely on it can either fix to a specific older version, or update their code to remove it.

shepmaster commented 9 months ago

If I create an error type not using SNAFU and check its documentation, it contains those deprecation warnings:

use std::fmt;

#[derive(Debug)]
pub struct Demo;

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

impl std::error::Error for Demo {}
image

I'm sure you've checked something similar, so I'm not sure I understand what your end goal is here. Can you try and restate so I understand better?

NWPlayer123 commented 9 months ago

So it does, interesting. I was mostly bringing this up because I found https://github.com/shepmaster/snafu/blob/main/src/no_std_error.rs#L6 as I was digging around how no_std works, and that's what I was mostly taking issue with.

In that case, you should use the same deprecation macro as the official Error does, as library authors are able to use it. image

shepmaster commented 8 months ago

around how no_std works

If possible for your case, I'd recommend that you use the unstable-core-error feature flag to use the version of Error that lives in the core library. Once that is stable enough, SNAFU will no longer have a reason to create its own Error trait.