Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POC: use snafu instead of derive_more for errors #1604

Closed
wants to merge 5 commits into from
Closed

Conversation

pkhry
Copy link
Contributor

@pkhry pkhry commented May 22, 2024

Description

Changing the library was somewhat easy, however:

  • snafu uses its own custom snafu::Error type in no-std contexts, therefore we needed to define a wrapper type that implements snafu::AsErrorSource for external error types and this led to a bit of boilerplate.
  • snafu doesn't support tuple variants yet, so its impossible to define an Error enum like this:
#[derive(Snafu)]
enum Error {
 #[snafu(display("example text {0}"))]
  MyEnum(AnotherError) 
}

it will be defined as:

#[derive(Snafu)]
enum Error {
 #[snafu(display("example text {source}"), context(false))]
  MyEnum {
    source: AnotherError
  } 
}
- for external types it will look like example below, given we defined `DisplayError` wrapper for compatibility
```rust
#[derive(Snafu)]
enum Error {
 #[snafu(display("example text {source}"), context(false))]
  MyEnum {
    #[snafu(source(from(AnotherErrorExternal,DisplayError)))]
    source: DisplayError<AnotherError>
  } 
}
  • This is a POC to gather some discussion whether it's better to go with snafu or use some other library or define Display/From by hand
  • This will also incur dowstream breakage for users of subxt-metadata, subxt-signer, subxt-core

@pkhry pkhry requested a review from a team as a code owner May 22, 2024 16:22
@niklasad1
Copy link
Member

This will also incur dowstream breakage for users of subxt-metadata, subxt-signer, subxt-core

It's because that snafu uses each variant as a struct instead of tuple?

// snafu
#[derive(Debug, snafu::Snafu)]
pub enum Error {
    #[snafu(display("Metadata Error: {source}"), context(false))]
    Metadata {
        /// Error source
        source: MetadataError,
    }
}

// dervive_more
#[derive(Debug, dervive_more::Display)]
enum Error {
    #[display(fmt = "Metadata Error: {_0}")]
    Metadata(MetadataError),
}

In downstream code then one has to do:

   // snafu
   if let Err(Error::Metadata { e }) = my_err {}

   // derive_more
   if let Err(Error::Metadata(e)) = my_err {}

Looks like a good solution to me :)
Would be nice to use context(false) globally on the Error type but that doesn't seem possible
because it depends on display attribute is used....

Copy link
Member

@niklasad1 niklasad1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

Copy link
Collaborator

@lexnv lexnv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! This approach also looks good, nice 👍

use core::fmt::{self, Debug, Display};

#[derive(Clone, PartialEq, Eq)]
pub struct DisplayError<T>(pub T);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Offhand I can't quite see what the reason for this is?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

snafu uses its own custom snafu::Error type in no-std contexts, therefore we needed to define a wrapper type that implements snafu::AsErrorSource for external error types and this led to a bit of boilerplate.snafu uses its own custom snafu::Error type in no-std contexts, therefore we needed to define a wrapper type that implements snafu::AsErrorSource for external error types and this led to a bit of boilerplate.

Most likely ☝️

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, I should have paid more attention reading :)

@jsdw jsdw marked this pull request as draft May 23, 2024 17:13
@pkhry
Copy link
Contributor Author

pkhry commented May 23, 2024

closing in favor of #1600

@pkhry pkhry closed this May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants