That is one option, not the only. The whole point would be “expose this type of error if something downstream is actionable based on the type”. Even if you went with an enum error handling approach you would still run into this dilemma if you want to handle “correctly”. So yes, a better identifying type for this type than ParseIntError would be ideal. You could still choose to go the untyped route and downcast as well. If you own the domain, this certainly is not “wrong”. If the error recovery path for every error is “fallback to a default port”, then you really don’t have to go the newtype route at all. But if there is multiple error recovery paths, then e.g. a PortSetError may be ideal.

score 1 · canonical

If I understand correctly, this sounds like an issue regardless of using eros or not. You are saying io:Error does not carry all the information you need? In that case, wouldn’t wrapping in a container type be enough – e.g. FileNotFound(io::Error, String) (or even deconstructing the io:Error to whatever shape you want). This is what I would do if I had a recovery tool or message tool up the call stack that could do something based on that type. But if you just want to propagate the information, I wouldn’t expose a plain io:Error if it is not actionable, but either way you could just add context .with_context(|| format!("Reading file {file_name}")). Depending on the recipient of this you could use .with_user_context instead. Another alternative is using the #[context] macro. See https://github.com/mcmah309/eros#context-macro and https://github.com/mcmah309/eros#context-placement-two-approaches

score 1 · canonical

I agree with your assertion. The example situation was not the best. It was more there to show the flow/api of eros. In real code don’t expose ParseIntError unless the caller cares about that exact error type. The 1. philosophy in the README is listed as “Error types only matter when the caller cares about the type, otherwise this just hinders ergonomics and creates unnecessary noise.”

score 1 · canonical

Somone just benchmarked this. After the first compilation, the same as time as anyhow. https://github.com/dpc/eros-bench

score 1 · canonical

Author here. The only downside in my opinion is that is does not work on no_std without alloc. But even this I just figured out with the inspiration of a colleague. Hopefully a PR for this will be up in the coming days – A lot of pieces to get right and conditional compilation, but the api will be the same. Overall for eros, I meticulously designed the api and am very happy with it. Full flexibility to the developer.

Yes there is an anyhow adapter behind the anyhow feature flag https://github.com/mcmah309/eros#anyhow

score 1 · canonical