My guess is to replace Syncthing-Fork which had a surprise ownership change a while back.

Get all the maintainers in a game of Rust and livestream it.

Interesting. I didn’t realize that was more than LDAP. Gonna look into it, thank you.

EDIT: Works great. Just disabled creating new repos, orgs, and local registrations and that’s pretty much what I want.

Me too. I can’t wait for federation to be done though. Requiring people to register on my personal instance to report bugs or contribute is quite a pain point.

I see you’re using strings. You can do that, but then you’ll lose control over formatting, and additional context info that might be contained in them.

I just haven’t figured out how to jam multiple error types into one enum variant yet. There’s no reason for the consumer of the module to get more pointless variants, so I’m not really sure I want an enum of enums, but maybe I’m overthinking it. I’ll fiddle more and check out your link later today.

I’m playing with this pattern, but it seems like it forces you to have a variant for every upstream error. For instance, I have this DatabaseError:

	#[derive(Clone, Debug, Error)]
	pub enum DatabaseError {
	    #[error("database error: {0}")]
	    Database(String),
	    #[error("failed to deserialize from DB: {0}")]
	    Deserialize(String),
	    #[error("failed to serialize input: {0}")]
	    Serialize(String),
	    #[error("unexpected error: {0}")]
	    Unexpected(String),
	}

But I might have 2 or 3 error types that turn into DatabaseError::Serialize. Then I end up doing custom From impls. Then I realize serde might be Serialize or Deserialize, so I’m back where I started.

Though I would like to have that chain of errors, but I haven’t figured out how to do the custom impl From yet (or if it ends up being useful in my case, even).

Thanks for the ideas.

Completely forgot about this one. Think I still like the other approach (implementing From) for most places, but I’ll keep this one in mind too, thanks.

This idea of having to write as little code as possible is stupid.

Is it? Not only is it less work, but generally makes the code way easier to reason about. In this case, instead of just seeing simple function calls explaining the logic flow, you visually have to parse all this weird extra cruft that is generally irrelevant to what the block is doing.

It’s a little verbose (like most of Rust), but I really like this approach. It’ll make a lot of logic easier to reason about. I missed that in the article, so thanks for pointing it out.

Rust’s explicitness and being forced to handle every case is so incredibly frustrating but also feels so right.

Thanks for posting this. I’m still trying to figure out the best technique to error handling in my programs. I just learned about anyhow the other day and kind of starting to work that in.

I’m so tired of having to reshape errors with match statements.

let result = match foo(a, b) {
   Ok(r) => r,
   Err(err) => {
       return Err(MyErrorEnum::Error(err.to_string()));
   }
};

This pattern is an annoying habit I keep finding myself repeating.