Rust already has most of what I want from error handling: explicit control flow, errors as values, and concise propagation with ?. The friction comes when deciding what to put in the error half of Result. We often end up choosing between precise types that require boilerplate and convenient types that hide which errors can occur. But precision and convenience do not have to be competing goals. Error types should compose as easily as the functions that return them.
so how would you approach exposing “port parsing failed” but not ParseIntError in programmatically-accessible way with eros? manual newtype + .map_err()?
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.
so how would you approach exposing “port parsing failed” but not
ParseIntErrorin programmatically-accessible way with eros? manual newtype +.map_err()?score 1 · canonical
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
ParseIntErrorwould 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. aPortSetErrormay be ideal.score 1 · canonical