Rust errors without dependencies

Take the example at https://docs.rs/thiserror/latest/thiserror/

- Struct variant fields are public, limiting how you evolve the fields and types

- Struct variants need non_exhaustive

- It shows using `from` on an error. What happens if you want to include more context? Or change your impl which can change the source error type

None of this is syntactically unique to errors. This becomes people's first thought of what to do and libraries like thiserror make it easy and showcase it in their docs.

> I took it as a statement of fact. It is a factual matter of whether `std::error::Error` has a point to it or not. And it definitively does. I use the error chain in just about every CLI application I've built. It's not even mostly pointless. It's incredibly useful and it provides an interoperable point for libraries to agree upon a single error interface.

Okay, I'm willing to give you this one. I haven't encountered this view among coworkers before. The consensus view in my circles was, there is potentially a very small upside if your consumer is willing to do the error chain song and dance, but most people don't, and you have a risk of a lot of complexity for no_std builds, so it's better to avoid. But that may be a biased take and there may be lots of applications where the error chains are really great, and I just haven't encountered them.

> The `Error` trait has been in `core` for about a year now. So you don't need any build complexity for it.

I actually had no idea that it has been in `core for a year now!!

I am very happy, this means that the situation has actually improved dramatically and there's no major downside to using `std::error::Error`.

I'm going to re-evaluate my choices. I have a lot of code that systematically avoids `std::error::Error`, and I'm not sure it's worth it to change it all, but there's probably no good reason to avoid it if it's in core now.

---

I think you are mistaken, however, about backtraces never being a part of std::error::Error. There are RFC's from 2018 years ago that talk all about it:

https://rust-lang.github.io/rfcs/2504-fix-error.html

Here's a withoutboats PR in 2020: https://github.com/rust-lang/rust/pull/72981

https://github.com/rust-lang/rust/pull/72981#issuecomment-66...

It may just be a matter of perspective -- if you don't count rust pre 1.0, then yeah it "never" involved backtrace. But in my company, we were trying to use rust even at that time for no_std targets, and trying to figure out where the puck was headed on std::error::Error was complicated. All the backtrace stuff made us think, maybe this is just not meant for us and we should rip it out, and we did eventually, although not without a lot of internal arguments.

> It's incredibly useful and it provides an interoperable point for libraries to agree upon a single error interface. > > And one `Error::provide` is stable, it will be even more useful.

Now it's clear to you that the "point" of it is error chains, that was maybe not a consensus view of the libs team on the day of 1.0.

Even in 2021 we have comments like this (https://github.com/rust-lang/rust/pull/72981#issuecomment-76...):

> We discussed this at the recent Libs meeting and came to the conclusion that stabilizing Backtrace without Error::backtrace wouldn't be a useful direction, given that Backtrace is designed around being carried alongside Errors. So for now we can consider the stabilization blocked pending figuring out the last bits of what a pluggable (whether stably or not) backtrace would look like.

>

> We can move design discussion over to #77384

Because if the only purpose was error chains, it could have been in core on the day of rust 1.0, as it is today. I think what actually happened is `fn backtrace(&self) -> Option` was removed shortly before 1.0, but there were some misgivings about that and some on the core team wanted to bring that back eventually. And that was the main reason that it could not move to core, because that would make it a breaking change to bring `fn backtrace` back. At least that's what I remember from PRs I followed at the time. (There may have been other reasons besides this though?)

So, hearing that it is now actually in core is great, that resolves uncertainty I've had for like 7 years. Thank you!

Yeah, the edition thing is cool, but there's also a cost to it, which is that over time you accumulate more and more support code in the compiler for really ancient editions.

I don't have a super good understanding of how it actually works in rustc. In C++ typically they would use name mangling tricks to try to keep new and old standard library symbols from clashing if they decided to break compatibility. Probably with rustc they are happier to leave it unspecified. I have a hard time building a mental model of what kinds of things would be totally impractical to change with an edition.

I'm trying to describe a rather large spectrum of situations, and how most of them are favorable (or not unfavorable) to anyhow.

I'm not saying the error domain is small per se.

Instead, one argument I'm making: what you're describing about errors bubbling up to the top layer, is what happens with the overwhelming majority of errors in my experience.

Whether the error space is large or small, just wait until you have an immediate need to treat one error different from the rest. It happens, it's just not common.

I didn't steelman the case for when to use enums, but in short: In a tiny error space or as valuable documentation.

(The doc value is undermined somewhat when projects use 1-big-error and functions that eg only returns 3 of the 6 possible errors)

I'm not advocating removing an Error enum. Just that writing one can and should be postponed, saving a lot of maintenance edits.

> points to an issue in the language or std library design.

Rust has a too-small stdlib because they want to avoid a calcified stdlib like C++ and Python, which both have too-big stdlibs.

This is a law of nature, your stdlib can either be too small or too big. It cannot be the right size. At least it isn't C.