so how would you approach exposing “port parsing failed” but not ParseIntError in programmatically-accessible way with eros? manual newtype + .map_err()?

score 1 · canonical

exposing ParseIntError in this way feels iffy: this isn’t a failure to parse just any int, this is a failure to parse a port in particular. suppose your address contains two ints (maybe you’re connecting to a redis db and you have a port and a db number): now ParseIntError is ambiguous. this breaks either ? or automatic widening: now you need to specify which particular int failed to parse, by doing something like .map_err(ParsePortError) manually (just #[context] won’t do if you want to change this programmatically, because #[context] doesn’t change types).

for that reason, I think impls like From<ParseIntError> for ConnectionError are anti-patterns, and generally you should try to wrap “low-level” errors like these into more semantic types (or variants, you can have ConnectionError::ParsePort(ParseIntError) and ConnectionError::ParseDb(ParseIntError)). would be nice to see some infrastructure for that, although I’m not sure if it’s doable without some heavy macro use.

(a separate question is whether you should expose underlying errors at all in any particular case: maybe redis will transition to named dbs, and you’d wish you just left that error opaque)

score 1 · canonical