Readit Newsshepmaster commented on Crates.io phishing attempt fasterthanli.me/articles/... · Posted by u/dmarto
An official post about this is at
https://blog.rust-lang.org/2025/09/12/crates-io-phishing-cam...
shepmaster commented on Error handling in Rust felix-knorr.net/posts/202... · Posted by u/emschwartz
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!
You are quite welcome; thanks for the kind words!
shepmaster commented on Error handling in Rust felix-knorr.net/posts/202... · Posted by u/emschwartz
> multiple error variants that reference the same source error type which I always had issues with in `thiserror`.
Huh?
#[derive(Debug, thiserror::Error)]
enum CustomError {
#[error("failed to open a: {0}")]
A(std::io::Error),
#[error("failed to open b: {0}")]
B(std::io::Error),
}
fn main() -> Result<(), CustomError> {
std::fs::read_to_string("a").map_err(CustomError::A)?;
std::fs::read_to_string("b").map_err(CustomError::B)?;
Ok(())
}
low_level_result.context(ErrorWithContextSnafu { context })?;
// vs
low_level_result.map_err(|err| ErrorWithContext { err, context })?;
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}")]
shepmaster commented on Error handling in Rust felix-knorr.net/posts/202... · Posted by u/emschwartz
I accept, however this requires to create many types with corresponding implementations (`impl From`, `impl Display`, ...). This is a lot of boilerplate.
In addition to the sibling comment mentioning thiserror, I also submit my crate SNAFU (linked in my ancestor comment). Reducing some of the boilerplate is a big reason I enjoy using it.
shepmaster commented on Error handling in Rust felix-knorr.net/posts/202... · Posted by u/emschwartz
I disagree that the status quo is “one error per module or per library”. I create one error type per function/action. I discovered this here on HN after an article I cannot find right now was posted.
This means that each function only cares about its own error, and how to generate it. And doesn’t require macros. Just thiserror.
> I create one error type per function/action
I do too! I've been debating whether I should update SNAFU's philosophy page [1] to mention this explicitly, and I think your comment is the one that put me over the edge for "yes" (along with a few child comments). Right now, it simply says "error types that are scoped to that module", but I no longer think that's strong enough.
[1]: https://docs.rs/snafu/latest/snafu/guide/philosophy/index.ht...
shepmaster commented on Error handling in Rust felix-knorr.net/posts/202... · Posted by u/emschwartz
I'm a recent snafu (https://docs.rs/snafu/latest/snafu/) convert over thiserror (https://docs.rs/thiserror/latest/thiserror/). You pay the cost of adding `context` calls at error sites but it leads to great error propagation and enables multiple error variants that reference the same source error type which I always had issues with in `thiserror`.
No dogma. If you want an error per module that seems like a good way to start, but for complex cases where you want to break an error down more, we'll often have an error type per function/struct/trait.
Thanks for using SNAFU! Any feedback you'd like to share?
shepmaster commented on Compiler Explorer and the promise of URLs that last forever xania.org/202505/compiler... · Posted by u/anarazel
As we all know, Cool URIs don't change [1]. I greatly appreciate the care taken to keep these Compiler Explorer links working as long as possible.
The Rust playground uses GitHub Gists as the primary storage location for shared data. I'm dreading the day that I need to migrate everything away from there to something self-maintained.
You can write code using the actor model with Tokio. But it's not natural to do so.
I tend to write most of my async Rust following the actor model and I find it natural. Alice Rhyl, a prominent Tokio contributor, has written about the specific patterns:
https://ryhl.io/blog/actors-with-tokio/