Just wanted to say, you single handedly made me a rust programmer.

Your answers on stack overflow and your crates have helped me so much. Thank you!

I accept, however this requires to create many types with corresponding implementations (`impl From`, `impl Display`, ...). This is a lot of boilerplate.

With that scheme, what about propagating errors upwards? It seems like you have to wrap all "foreign" error types that happen during execution with an explicit enum type.

For example, let's say the function frobnicate() writes to a file and might get all sorts of file errors (disk full, no permissions, etc.). It seems like those have to be wrapped or embedded, as the article suggests.

But then you can't use the "?" macro, I think? Because wrapping or embedding requires constructing a new error value from the original one. Every single downstream error coming from places like the standard library has to go through a transformation with map_err() or similar.

It’s a nice, well-written and well-reasoned article, and yet after shoveling through all the boilerplate it offers as the solution I can’t help but “WTF WTF WTF ...”[1].

[1] https://danluu.com/wat/

Thanks for sharing!

The only thing I disagree with is error wrapping. While I agree that the main error should not expose dependencies, I find it useful to keep a `cause` field that corresponds to the inner error. It's important to trace the origin of an error and have more context about it. By the way, Rust's [Error] trait has a dedicated `cause` method for that!

[Error] https://doc.rust-lang.org/nightly/core/error/trait.Error.htm...

Yes! Thank you!

The "status quo" way erodes the benefit of Rust's error system.

The whole point (in my mind at least) of type safe errors is to know in advance all if the failure modes of a function. If you share an error enum across many functions, it no longer serves that purpose, as you have errors that exist in the type but are never returned by the function.

It would be nice if the syntax made it easier though. It's cumbersome to create new enums and implement Error for each of them.

> also that the language should make this pattern much easier

Open sum types? I’m on the fence as to whether they should be inferrable.

You return an error specific to that function.

If it internally has a `InnerFuncErr::WriteFailed` error, you might handle it, and then you don't have to pass it back at all, or you might wrap it in an `OuterFuncErr::BadIo(inner_err)`or throw it away and make `BadIo` parameterless, if you feel that the caller won't care anyways.

Errors are not Exceptions, you don't fling them across half of your codebase until they crash the process, you try to diligently handle them, and do what makes sense.

So you don't really care about the union.

There's a bunch of different situations that can be discussed, and it's hard to generalise. However:

Your function typically has a specific intent when it tries to call another function. Say that you have a poorly designed function that reads from a file, parses the data, opens a DB connection and stores the data.

Should I really expect an end-user to understand an error generated by diesel/postgres/wtfdb? No, most likely I want to instruct them to generate debug logs and report an issue/contact support. This is most likely the best user experience for an application. In this case, each "action" of the function would "hide" the underlying error––it might provide information about what failed (file not found, DB rejected credentials, what part of the file couldn't be parsed, etc), but the user doesn't care (and shouldn't!) about Rust type of diesel error was generated.

To answer your question specifically, I might go without something like this:

    #[derive(Debug, Error, Clone)]
    pub enum MyFunctionError {
        #[error("unable to read data from file: {0}")]
        ReadData(String),

        #[error("failed to parse data: {0}")]
        Parse(String),

        #[error("database refused our connection: {0} (host: {1}, username: {2})")]
        DatabaseConnection(String, String, String),

        #[error("failed to write rows: {0}")]
        WriteData(String),
    }

When building a library, however, yes, I most likely do want to use `#[from] io::Error` syntax and let the calling library figure out what to do (which might very well giving the user a userful error message and dumping an error log).

This is eerily reminiscent of the discussions about Java’s checked exceptions circa 25 years ago.

That's only the case when your per-function error sets are "flat" (directly contain "leaf" errors from many layers below).

You can avoid this issue if you deeply nest the error types (wrap on every level). It you change an error that's not deeply-matched anywhere, you only need to update the direct callers. But "deep" errors have some tradeoffs [1] too

[1]: https://news.ycombinator.com/item?id=44420061

This shouldn’t happen unless you’re actively refactoring the function and introducing new error paths. Therefore, it is to be expected that the cake hierarchy would be affected.

You would most likely have had to navigate up and down the caller chain regardless of how you scope errors.

At least this way the compiler tells you when you forgot to handle a new error case, and where.

Sometimes that error was being smuggled in another broader error to begin with, so if the caller is having to go spelunking into the .description (or .message) to know, that's a very serious problem. The distinction I make is: if the caller knew about this new type of error, what would they do differently?

A sibling reminded me of the blog post that convinced me. Here it is: https://mmapped.blog/posts/12-rust-error-handling

See the two articles linked in the sibling comments

Semantics matter. This is a mistake C++ has made and will probably pay for when it eventually tries to land pattern matching. Rust knows that Option<Goose> and Result<Goose,()> are completely different semantically, likewise Result<Happy,Sad> and Either<Happy,Sad> communicate quite different intents even if the in-memory representations are identical.

I really wish Rust had proper union types. So much ceremony over something that could be Foo | Bar | Error

> I do not want to go to the hassle of defining some new error types everywhere, I just want to use equivalents to runtime_error or logic_error.

You can use anyhow::Error everywhere. If you need to "catch" a specific wrapped error, you can manually document it on the "throwing" method and downcast where you "catch". It's very similar to exceptions (checked-but-unspecific `throws Exception` in Java), but better, because Result and ? are explicit.

It isn't even the proliferation per se, rather that integration them requires macros, boilerplate code and reaching out to external crates, for what should be builtin.

I prefer `derive_more` than thiserror. Because it is a superset and has more useful derive I use.

color-eyre is better than anyhow.

I rather take the approach that basic language features are in the box.

Too much innovation gets out of control, and might not be available every platform.

Just please let us not end up with something like Node.js where we use a crate that has <10 LOC. Irks me. And if Rust ends up like that, I will never switch. It already builds ~50 crates for medium-sized projects.

> every rust project starts with cargo install tokio thiserror anyhow.

True, almost. Not mine

Makes me sad

You certainly can use thiserror to accomplish the same goals! However, your example does a little subtle slight-of-hand that you probably didn't mean to and leaves off the enum name (or the `use` statement):

    low_level_result.context(ErrorWithContextSnafu { context })?;
    low_level_result.map_err(|err| CustomError::ErrorWithContext { err, context })?;

- You don't need to move the inner error yourself.

- You don't need to use a closure, which saves a few characters. This is even true in cases where you have a reference and want to store the owned value in the error:

    #[derive(Debug, Snafu)]
    struct DemoError { source: std::io::Error, filename: PathBuf }

    let filename: &Path = todo!();
    result.context(OpenFileSnafu { filename })?; // `context` will change `&Path` to `PathBuf`

----

As an aside:

    #[error("failed to open a: {0}")]

I regularly get super confused by what coerces and what doesn’t. I swear there’s cases where ? works but into() does not.

It’s many things. But simple ain’t one of them =D

No, I said it reminds me of them. It definitely avoids some of the flaws of exceptions. Not the same solution.

Yep. I wish Rust supported proper union types. Typescript gets it right, I just don't want to be writing Javascript...

I've even decided to turn my parent comment into a blog post [1]. It also fixes numerous typos, so qoute the blog version.

[1] https://home.expurple.me/posts/go-did-not-get-error-handling...

> At least we won't repeatedly pay the penalty.

Another promising solution for that is caching proc macro expansions in the compiler.

"How I reduced (incremental) Rust compile times by up to 40%": https://web.archive.org/web/20250311042037/https://www.coder...

An error type per function doubles as documentation. If you treat all errors as the same it doesn't matter, but if you have to handle some, then you really care about what actual errors a function can return.

Rust is trying very hard to compete with C++. That includes giving everyone a hammer so that every problem can be a thumb.

> Yes. Macros are a hammer, but not everything is a nail.

Overuse of macros is a symptom of missing language capabilities.

My biggest disappointment in Rust (and probably my least popular opinion) is how Rust botched error handling. I think non-local flow control (i.e. exceptions) with automated causal chaining (like Python) is a good language design point and I think Rust departed from this good design point prematurely in a way that's damaged the language in unfixable ways.

IOW, Rust should have had _only_ panics, and panic objects should have had rich contextual information, just like Java and Python. There should also have been an enforced "does not panic" annotation like noexcept in C++. And Drop implementations should not be allowed to panic. Ever.

God, I hope at least yeet gets in.

It’s a bit confusing sometimes with macros that create types that don’t seem to exist. But usually when I work with code I use an IDE anyway and “go to definition” will bring me to where it’s defined, even when it’s via a macro.

Still generally prefer the plain non-macro declarations for structs and enums though because I can easily read them at a glance, unlike when “go to definition” brings me to some macro thing.

Doesn't something like the following break the trail in pretty much all languages?

    from package import *

You can import everything from a module with a *, but most people seem to prefer to import things explicitly. But, yes, you can generally figure out easily where things are coming from!

Increase of compile times, on a already blazing fast compiler.

Debugging, especially when it lacks the tooling of a Lisp or Scheme REPL/IDE.

This has problems as soon as it hits generics and lifetimes.

That being said, I think a limited version of the feature that disallows the the same type with divergent lifetimes or even all generics would still be useful and well liked.