thiserror vs snafu

[kazk]

Background: kube uses thiserror and kube-runtime uses snafu.

How are you finding working with snafu? What benefits do you find with it over thiserror?

I ask because I was kind of thinking to propose unifying under thiserror instead because every time i make another app, I have started reaching for it instead because of ergonomics:

• snafu's error enum ends up being 5 lines per impl (when using a source + backtrace) rather than thiserror's 2
• snafu's error variants all have to be imported into scope and causes extra cycles when developing

@clux (#450 (comment))

---

A small question though. How are you finding working with snafu? What benefits do you find with it over thiserror?

IMO, the big benefit is that the context selectors push you towards having many smaller and more specific error types that act as a sort of semantic backtrace ("file not found while finding Y while reconciling X"), rather than the more or less unmanageable kube::Error ("something has gone wrong in library X, have fun figuring out why").

• snafu's error enum ends up being 5 lines per impl (when using a source + backtrace) rather than thiserror's 2

snafu is agnostic to struct vs tuple variants, you can do:

#[derive(Debug, Snafu)
pub enum Error {
   #[snafu(display("IO error"))]
   Io(#[snafu(source)] std::io::Error, #[snafu(backtrace)] Backtrace)
}

The current state in kube-derive is more about my own bias towards struct-style enums.

Backtraces can also be inherited from other snafu errors, which would save you an item.

• snafu's error variants all have to be imported into scope and causes extra cycles when developing

Not really, if you follow snafu's recommended error-enum-per-module style. The enum is the external interface of the module, the context selectors are an implementation detail.

@teozkr (#450 (comment))

[clux]

My first complaint there pretty much goes away as per @teozkr 's comment: #450 (comment):

snafu is agnostic to struct vs tuple variants, you can do:

#[derive(Debug, Snafu)
pub enum Error {
    #[snafu(display("IO error"))]
    Io(#[snafu(source)] std::io::Error, #[snafu(backtrace)] Backtrace)
}

Wasn't aware of that, their documentation is all structs.
Does this mean you can do things like:

myfailing_fn().await.context(Error::Io)?

as well, or would you have to do:

myfailing_fn().await.context(Io)?

and have the Io symbol in scope?

The many small error types ideology seems great in theory, but wouldn't that force us to create a kube::Error type that mimics the module structure of kube? E.g. kube::Error contains ConfigError, ClientError, ApiError, etc, each of which are further error enums maching the files therein?

[nightkr]

Does this mean you can do things like:

myfailing_fn().await.context(Error::Io)?

You can use Result::map_err just like with thiserror, as long as the source is the only tuple field (just like with thiserror).

The many small error types ideology seems great in theory, but wouldn't that force us to create a kube::Error type that mimics the module structure of kube? E.g. kube::Error contains ConfigError, ClientError, ApiError, etc, each of which are further error enums maching the files therein?

With this strategy there wouldn't be a kube::Error at all, Api just returns an ApiError (which might embed ClientError as one or more variants, for example).

[kazk]

I've never tried tuple variants (the extra lines doesn't bother me), but I just found this shepmaster/snafu#61.
I guess for tuple variants, display can't access the values?

[kazk]

What benefits do you find with it over thiserror?

thiserror is minimal, and we forget about it after deriving errors. This can be nice for smaller projects, but it can lead to a huge error enum for larger ones if we aren't careful. It becomes difficult for anyone (both users and maintainers) to find how exactly a function can fail, especially with From and ?.
For kube, there are some error variants that rg SomeName doesn't match, but we can't assume it's unused. Users need to constantly ignore irrelevant error variants when using kube.

snafu makes it difficult to let that happen. It gives us an opinionated way to organize errors and be explicit about them.

How are you finding working with snafu?

After understanding their idea, it's been nice so far. One error enum per module pattern has been helpful to think about the error cases and to set clear boundaries.

[clux]

Thank you both. Perhaps my mistake is to optimise for small stuff and finding snafu marginally worse for the small module cases, rather than thinking sufficiently about the large library cases like kube, where it probably would be better.

If both of you are happy with it, then I think we should probably just unify around snafu. Having a consistent interface is the bigger issue to me, but it also sounds like snafu can make things better.

[kazk]

Just to be clear, I haven't used it in large projects or seen any large projects using it, so I actually don't know if snafu scales well. I do think snafu makes it easier to organize errors in a way that scales better (providing a framework for errors) and I trust them over myself for that.

I'm actually fine with us continue using thiserror (much more popular and stable). But the huge kube::Error and less explicit errors in general does bother me. To fix that, I think we'll end up with something similar to snafu, though. Maybe we should study other crates that uses thiserror and see how they're doing it.

---

From a user's point of view, the errors stood out because it feels unpolished compared to the rest of kube which I think is intuitive and prevents misuse.

I think it's worth trying snafu to see how it can improve kube by following their recommended pattern without worrying about backwards compatibility. We can decide what to do based on that and anything else we find.

[kazk]

Some relatively complex crates using thiserror (https://lib.rs/crates/thiserror/rev):

• snapview/tungstenite-rs (Multiple errors, but not specific enough and some with many variants. That lead to us introducing catch all WsOther error variant at one point. https://github.com/clux/kube-rs/pull/373/files)
• opentelemetry (Multiple errors that's specific to modules, e.g., crate::trace::TraceError (3 variants) and crate::metics::MetricsError (10 variants))
• getsentry/sentry-rust (Many errors in each sub crate. Not sure how explicit they are.)
• tikv/rust-prometheus (A single error, but only 5 variants)
• samscott89/serde_qs (A single error, but only 7 variants)

[kazk]

Some relatively complex crates using snafu (https://lib.rs/crates/snafu/rev):

• awslabs/tough (Multiple errors, but not error enum per module pattern)
• awslabs/tuftool (Multiple errors, but not error enum per module pattern)
• awslabs/coldsnap (Multiple errors, following snafu pattern)
• jgallagher/amiquip (A single large error)
• XAMPPRocky/octocrab (A single small error)
• kube-runtime (Multiple erros, following snafu pattern)
• cloudevents/sdk-rust (Multiple errors, per module?)
• rust-bio/rust-bio (unreleased version actually switched to thiserror Switch from snafu to thiserror rust-bio/rust-bio#400, but still doing error per module)

influxdb_iox
They have a style guide for errors following snafu pattern. https://github.com/influxdata/influxdb_iox/blob/500c237f62bd27cc4f4249301e108075ebbbab4c/docs/style_guide.md#errors