anyhow VS pico-args

Depending on your use case, thiserror and/or anyhow.

There is ? as well as the anyhow(https://github.com/dtolnay/anyhow) crate that deals with long nested result chains.

There are crates out there that help you reduce this boiler plate. thiserror is good for creating custom errors and color-eyre or anyhow are good for dynamic errors.

Give anyhow a look.

I've brought anyhow::Result into scope, making error handling super easy to use. We don't need to specify all our Error types. It can automatically convert any errors that implement std::error::Error, which should be all of them. If an error propagates all the way up to main(), we'll get all the info it's captured printed to stdout.

Alternatively, if you've got a lot of error types and you're outside a library (so directly in a binary where you don't plan to reuse code elsewhere) you can use anyhow. This gives you an error type you can basically propagate any other error through. On top of that you can attach context information at every return. It's basically a more complicated Result>.

One approach is to define a separate error type for each crate and then use anyhow, eyre or Box to wrap the error, whever a function can return errors originating in several different crates.

Have you tried anyhow and thiserror for making it as simple as .context("Message") or ? to type-convert and propagate errors up the call stack?

That's because the maintainer does not consider it an issue but an implementation detail: https://github.com/RazrFalcon/pico-args/issues/15

Maybe pico-args then?

If I forget to get around to it, would you mind poking RazrFalcon/pico-args about adding it to the comparison chart? I really like using that thing as something I can link people to with just a quick explanation of that particular trade-off.

If fewer dependencies is better, you can't get much fewer than pico-args, which has zero dependencies.

You might also want to check out pico-args, Gumdrop, and lexopt to see if any of them meet your needs.

For example, The Rust compiler isn't slow; we are. and pico-args: Alternatives.

For example, I'd love to go from StructOpt to Gumdrop for parsing command-line arguments and cut my compile times and output size by an order of magnitude, but Gumdrop uses String internally, which means it'll panic if it encounters a Windows path with un-paired surrogates or a mojibake'd posix path... some of which I actually have.