1,167 karma · joined February 6, 2011
[1]: http://integer32.com/ [2]: https://www.manning.com/livevideo/rust-in-motion?a_aid=jgoulding&a_bid=6a993c2e
I like, use, and write macros, but this isn't fully true. For example, recent Rust versions allow writing identifiers directly in the format string:
println!("{some_identifier}")
[1]: https://github.com/rust-lang/rust-analyzer/issues/11260#
https://doc.rust-lang.org/std/thread/fn.available_parallelis... — Rust 1.59
> there's no reason why you couldn’t safely promote a u8, u16, or u32 into a usize
The people running Rust on a 16-bit architecture (e.g. AVR) would disagree. On those platforms, usize is 16-bit, so promoting u32 to usize would not be possible.
I _do_ wish there was a nicer way to declare up-front "I *never* want this crate to compile on something smaller than 32-bit (or 64-bit), so assume that".
IIRC, similar ideas like this have floated around under the name of a "platform compatibility lint".
Sometimes I will actually create the fixup commits and push them separately to communicate with the submitter, but then squash them into the appropriate places in history before merging.
The only technical issue is when someone has signed their commits, as I obviously cannot re-sign them :-). In that case, I call it out to them and let them re-sign if they want before I merge.
If I expect or hope the contributor to become a long-term collaborator, I will submit the comments and wait for them to fix it. I'd rather they learn
If I don't expect them to stay around, I'll make the changes, force-push to their branch keeping their authorship, submit the comments, and let them know what I did and link to the diff caused by just the force push. I'll then ask them if it's OK and let the PR sit for a few days or until they respond, then I'll merge it.
---
The more of your expectations you can automate or at least document (e.g. in CONTRIBUTING.md) the easier it is.
Do you have an example of this configuration somewhere you could share? Or are you using something existing, like https://github.com/jasonrudolph/ControlEscape.spoon ?
[1]: https://github.com/integer32llc/rust-playground/pull/777
https://github.com/shepmaster/stack-overflow-relay/blob/273a...
[1]: https://github.com/integer32llc/rust-playground/pull/777
It has been const since Rust 1.39 (https://doc.rust-lang.org/std/string/struct.String.html#meth...)
With that example, since you use `Result::map_err` and specify the specific variant, you aren't really using anything from thiserror at the site of the `?`, correct?
Most usages I have seen, people use `#[from]`, which would end up having conflicting implementations. Is there a reason you didn't use `#[from]` for `ParseConfig`?
I'd like to provide a fair comparison [1] in the documentation, but I don't know thiserror / anyhow well enough to feel like I'd give them the credit they are due.
That said, to my knowledge, thiserror doesn't allow you to take an `io::Error` and sort it into two different enum variants (like the `Reading` and `Opening` variants in my grandparent example). To me, those are vastly different error states that just both happen to have the same error type. You can extend the metaphor with any larger error type from a crate (e.g. `reqwest::Error`).
Anyhow requires using a trait object (and potentially downcasting) and I prefer avoiding those when possible.
> seemed the popularly recommended way
Absolutely. The author of those crates is a giant in the Rust community [2] (they are also the author of serde, syn, and quote, for example!). If those crates suit your situations, then by all means — use them. I'd much rather the Rust community have better error types and messages by whatever means available. Even using `String` via `Box<dyn Error>` is better than nothing.
> you won't get autocompletion
You should, at least if you use rust-analyzer. I use it via emacs and have these settings enabled, but I think they were going to be the default:
(lsp-rust-analyzer-cargo-load-out-dirs-from-check t)
(lsp-rust-analyzer-proc-macro-enable t)
Yes. I'm not sure exactly what other response you'd expect from the author/maintainer of a library when they've already made a post encouraging other people to use it. ¯\_(ツ)_/¯
> when you could just use e.g., `.map_err(|source| Error::Opening { source, filename })`
That's not equivalent, as `filename` is a `&str` but becomes a `String` when stored in the error. SNAFU automatically calls `Into::into` for you, so the closest would be:
.map_err(|source| Error::Opening { source, filename: filename.into() })
There's also the possibility of automatic construction of values (backtraces, location information, the current time, things captured from globals / thread locals, etc.)
Beyond `.context`, SNAFU also implements the `Error` trait (and associated methods like `Error::source`).
There's also convenience methods and macros to create leaf errors, those that originate in your code.
> obviously the `#[snafu(display(...))]` macros could just be moved into a `impl Debug for Error`
I'll assume you mean `Display`, not `Debug`. That also not quite true, as SNAFU offers a shorthand syntax that isn't yet in stable Rust:
"Unable to read {filename}"
"Unable to read {}", filename
"Unable to read {filename}", filename = filename
All code could have been written by your own hand or otherwise inlined. Your response feels (needlessly) highly dismissive of another person's work.
(emphasis mine)
This is a huge belief of mine as well. I call it a "semantic stacktrace".
I actually go as far as to say that _most of the time_ backtraces in errors are an antipattern, as it gives a false sense that an error is actionable ("oh, just look in the code!").
I even try to make it such that each leaf error is constructed in exactly one place so that grepping for the error identifies that one location.
Like everything, it can be a balancing act. I tend to be free about creating error types (one per module, usually, but it's not strange for me to create more). When you implement `std::error::Error` (to be able to make error trait objects) and have a tool like SNAFU (to make error enums), then having more error types isn't much of a hindrance in my experience.
> I’ll start with `anyhow` if I’m writing library code and then refactor to enums later
The newest (beta) version of SNAFU actually strives to make this case even smoother. There's a `whatever!` macro that you can use to create stringly-typed errors and then migrate case-by-case to an enum. Check out the docs for some example usage.
This is a point of debate[1] among the error-handling working group.
[1]: https://github.com/rust-lang/project-error-handling/issues/4...
You can also use enums, as shown in the post. You don't need trait objects.
EDIT 1
> without needing to use boxed trait objects [...] `anyhow`
It's my understanding that anyhow uses trait objects. The first sentence of its document says "This library provides anyhow::Error, a trait object based error type"
EDIT 1 END
> which have nice downcasting API
I'm not a fan of downcasting when not _absolutely_ necessary.
See my sibling comment about SNAFU for an alternate that allows keeping different errors separate while unifying them.
It simplifies constructing your own "leaf" errors and streamlines the ability of collecting multiple types of errors while attaching more context to them (e.g. filenames, stack traces, user ids, etc.). It allows you to smoothly switch from "stringly-typed" errors to strongly-typed errors. You can create opaque errors to avoid leaking internal implementation details into your public API.
Applied to the code in the post:
use snafu::prelude::*;
use std::{fs::File, io::prelude::*};
#[derive(Debug, Snafu)]
enum Error {
#[snafu(display("Unable to open {filename}"))]
Opening {
source: std::io::Error,
filename: String,
},
#[snafu(display("Unable to read {filename}"))]
Reading {
source: std::io::Error,
filename: String,
},
#[snafu(display("Unable to parse {buffer} as a number"))]
Parsing {
source: std::num::ParseIntError,
buffer: String,
},
}
fn read_number_from_file(filename: &str) -> Result<u64, Error> {
let mut file = File::open(filename).context(OpeningSnafu { filename })?;
let mut buffer = String::new();
file.read_to_string(&mut buffer)
.context(ReadingSnafu { filename })?;
let buffer = buffer.trim();
let parsed: u64 = buffer.parse().context(ParsingSnafu { buffer })?;
Ok(parsed)
}
Importantly, this example demonstrates a key feature of SNAFU, here shown as "not all `io::Error`s are the same". Opening the file and reading the file are two separate error conditions and should not be lumped together as one.
{ "alpha": "3", "beta": "5" }
{ "alpha": "dog", "beta": "cat" }
{ "alpha": ["must be a number"], "beta": ["must be a number"] }
It sounds like you are saying that I'd be able to get something isomorphic to the above, so that's good.
In addition to the above, I'd like to be able to say that once the values have been validated (a.k.a. parsed) as numbers, then `beta` must always be greater than `alpha`. This is a type of validation across fields that also depends on earlier validations (parsing, transformation, etc.) succeeding.
Yep, which is why I expect that a graph is needed to model the validations that I picture in my mind.
> so that they can opt in to discarding error messages
Do you have any small examples of when you'd want to discard error messages?
From some thought experiments I’ve done, I feel like my ideal solution would be to define a graph based on my data structure with validations as the edges. Then traverse the graph as far as possible before reporting errors.
This would allow validations to build on each other, as well as validating arbitrary combinations of fields.
I’ve never sat down to actually implement it though…
This is exactly the path that my SNAFU library takes. It’s a procedural macro attached to an enum that generates the From, Display and Error traits for you.
This way, consumers of your code don’t need to know anything beyond the fact that you implement Error and any inherent public methods or traits you choose to expose. The implementation provided by SNAFU is internal to your code.
`Option::deref` is a good choice here.
> I could then go to an internet facing machine and run a cargo command
Copy over your Cargo.toml to that machine, run vendor, copy the vendor files back.
https://doc.rust-lang.org/cargo/commands/cargo-tree.html
Download all dependencies locally: