Rust errors without dependencies • Hacker News Board

Re: Rust errors without dependencies

#31

Post by vsgherzi » Sun, Dec 28, 2025, 9:25 PM UTC

j1elo wrote: post #2

That's quite a good amount of boilerplate to create a custom, project-specific handling of errors, which itself can have bugs. During reading I thought " anyhow , at this point you are half way to reinvent the wheel and write your own "anyhow'". I agree with avoiding an explosion of dependencies; but not at any cost. In any case if custom error handling works, then why not. It's just that it feels like a deviation to…

It is, this is the most verbose way of doing it, it can easily be made smaller. The main reason is rust exposes this where other languages tend to hide it so programmers aren’t used to having so much code on error cases. Just my opinion of course

Re: Rust errors without dependencies

#32

Post by burntsushi » Sun, Dec 28, 2025, 9:26 PM UTC

osiris88 wrote: post #26

burntsushi wrote: post #18

Earlier quoted context omitted.

> It was `std` only and linked to a concept of backtraces, which made it a non-started for embedded. It just seemed to me that it was a bad idea ever to use it in a library and that it would harm embedded users. It was never linked to backtraces. And if you used `std::error::Error` in a library that you also wanted to support in no-std mode, then you just didn't implement the `std::error::Error` trait when the `std`…

By error accumulation, I mean a tree of errors, not a simple chain. The chain is only useful at the very lowest level. The tree allows you to say e.g. this function failed because n distinct preconditions failed, all of which are interesting, and might have lower level details. Or, I tried to do X which failed, and the fallback also failed. The error chain thing doesn’t capture either of these semantics properly. Che…

I don't see any reason for something like `rootcause` to become foundational. Most errors are a linear chain and that's good enough for most use cases.

It's correct to say that `std::error::Error` does not support a tree of errors. But it is incorrect to say what you said: that it's pointless and doesn't allow error accumulation. It's not pointless and it does provide error accumulation. Saying it doesn't is a broad overstatement when what you actually mean is something more precise, narrow and niche.

Re: Rust errors without dependencies

#33

Post by vsgherzi » Sun, Dec 28, 2025, 9:26 PM UTC

IshKebab wrote: post #5

I still think it's kind of mad that the standard library doesn't have better options built in. We've had long enough to explore the approaches. It's time to design something that can go into std and be used by everybody. As it is any moderately large Rust project ends up including several different error handling crates.

I do think it’s just a newness issue and the community is still deciding what’s right

Re: Rust errors without dependencies

#34

Post by andrepd » Sun, Dec 28, 2025, 9:29 PM UTC

drnick1 wrote: post #4

> I want less code. I want to limit the amount of 3rd party code I pull in. This is mostly due to supply chain disasters over on NPM scaring me and the amount of code dependencies bringing in see rust dependencies scare me. And this is basically why I like the C/C++ model of not having a centralized repo better. If I need some external piece of software, I simply download the headers and/or sources directly and place…

> Unless somehow these are compromised at the time of download, I will never have to worry about them again.

But this is exactly what rust does x) `cargo add some_crate` adds a line `crate_name = "1.2.3"` to your project config, downloading and pinning the dependency to that exact version. It will not change unless you specifically change it.

Re: Rust errors without dependencies

#35

Post by burntsushi » Sun, Dec 28, 2025, 9:29 PM UTC

epage wrote: post #25

burntsushi wrote: post #11

Earlier quoted context omitted.

I'm on libs-api and I'd personally be on board with something like `thiserror` coming into `std`. But it would need a champion I think.

I think we should provide the building blocks (display, etc like derive_more) rather than a specialized version one for errors (thiserror). I also feel thiserror encourages a public error enum which to me is an anti-pattern as they are usually tied to your implementation and hard to add context, especially if you have a variants for other error types.

Yeah I used the weasel-y "something like" for exactly these reasons. :-)

Re: Rust errors without dependencies

#36

Post by tempest_ » Sun, Dec 28, 2025, 9:32 PM UTC

drnick1 wrote: post #4

> I want less code. I want to limit the amount of 3rd party code I pull in. This is mostly due to supply chain disasters over on NPM scaring me and the amount of code dependencies bringing in see rust dependencies scare me. And this is basically why I like the C/C++ model of not having a centralized repo better. If I need some external piece of software, I simply download the headers and/or sources directly and place…

The C/C++ model should go back to 80s where it belongs.

You can vendor deps with cargo if you want but fighting cmake/make/autoconf/configure/automake build spaghetti is not my idea of a good time.

Re: Rust errors without dependencies

#37

Post by rcxdude » Sun, Dec 28, 2025, 9:32 PM UTC

andrepd wrote: post #34

drnick1 wrote: post #4

> I want less code. I want to limit the amount of 3rd party code I pull in. This is mostly due to supply chain disasters over on NPM scaring me and the amount of code dependencies bringing in see rust dependencies scare me. And this is basically why I like the C/C++ model of not having a centralized repo better. If I need some external piece of software, I simply download the headers and/or sources directly and place…

> Unless somehow these are compromised at the time of download, I will never have to worry about them again. But this is exactly what rust does x) `cargo add some_crate` adds a line `crate_name = "1.2.3"` to your project config, downloading and pinning the dependency to that exact version. It will not change unless you specifically change it.

well, not quite. It'll go into the lockfile and you won't get a new version if you just build again, but if you add or remove a dependency that version may shift around a bit as a part of dependency resolution.

Re: Rust errors without dependencies

#38

Post by sunshowers » Sun, Dec 28, 2025, 9:34 PM UTC

athrowaway3z wrote: post #10

My controversial take on Rust errors is to use anyhow everywhere until you have an immediate demand for explicit Enums. YANGNI The pros for using anyhow are big: Easily stack errors together - eg file.open().context(path) -, errors are easily kept up to date, and easy to find where they occur. An enum error is pleasing when you're finished, but cumbersome in practice. It's niche situation that you need to write a fun…

LLMs are pretty good at generating and maintaining error enums for you these days.

Re: Rust errors without dependencies

#39

Post by vsgherzi » Sun, Dec 28, 2025, 9:34 PM UTC

zahlman wrote: post #3

> In the recent Cloudlfare outage Cloudlflare's proxy service went down directly due to an unwrap when reading a config file. Me and many other developers jumped the shark, calling out Cloudflare on their best practices. In Cloudflare's defense they treated this file as trusted input and never expected it to be malformed. Due to circumstances the file became invalid causing the programs assumption's to break. "Truste…

Nodejs and rust are the languages that I’m most familiar. I mostly mean that part to serve as a contrasting paragraph between the two paradigms. The amount of code is high in rust, even higher due to me writing the most pedantic error possible. If you really want a more try catch approach you can do that with something like dyn error or anyhow. The point is it gives you choice

Re: Rust errors without dependencies

#40

Post by rcxdude » Sun, Dec 28, 2025, 9:35 PM UTC

drnick1 wrote: post #8

dkdcio wrote: post #7

Earlier quoted context omitted.

you could just do that with Rust, right? you’re just saying cargo makes it too easy not to I’m very tempted to go this direction myself with Rust, vendoring in and “maintaining” (using Claude Code to maintain) dependencies. or writing subsets of the crates I need myself and using those. the sprawl with Rust dependencies is concerning

Yes of course you could do this in Rust. It's just that every resource out there promotes the usage of Cargo, and sells this as an "improvement" over the old school way of managing dependencies manually.

it's mainly an improvement because the rust ecosystem has a standardized way to build and distribute packages, so you can reliably add a dependency without build system pain. If you don't think having a reference to a central repo is a good way to go, you can vendor or even just pin your dependencies.