In several of my libraries, I have functions taking callbacks as arguments and, depending on the application, these callbacks may generate errors or not. In such a situation, Is the idiomatic solution to have two functions, say
where Error is an error struct with a slot taking a generic E to propagate errors? To name the two functions exe, I introduced a sub-module err; is this the expected presentation?
Why not? May you elaborate? With #![feature(exhaustive_patterns)] (hopefully enabled by default in the future), the struct case that holds the error E may simply be ignored in pattern matching. A single error type for both cases but with refutation of some patterns when fit seems ideal to me.
and for convenience you can implement this trait for closures too. If you want to do something with these errors, you can add trait bounds to them too. For example if these operations can time out and you want to report that using their error type, add where Self::Error: From<MyTimeoutError>.