Use own error type for API about calloop

[elinorbgr]

Yes, definitely. Notably, process_events() should return a result that indicates, when an error occurred, if it came from the polling machinery itself or from one of the event sources, in which case it could be a Box<dyn Error>. Probably worth thinking to some mechanism that allows to easily detect which source errored, to act upon that if possible/necessary.

[detly]

Excellent, we can discuss the general approach here and then I'll code it up.

I tend to avoid Box<dyn Error> - basically it doesn't do a whole lot that anyhow or thiserror don't achieve between them. Both of those libs will happily work with (ie. wrap, allow unwrapping, combine) errors that implement std::error::Error, so we should be fine there.

My first suggestion would be to have a calloop::CalloopError that

• implements std::error::Error
• has From impls from std::io::Error into itself
  • possibly has a few distinct types that correspond to obvious std::io::ErrorKinds without going overboard
• has From impls from std::error::Error into itself
• has enough additional information that the event source can at least be identified (access it directly might have ownership issues, because the loop owns the source, but eg. the handle's registration token or the source's token could be recorded)

Off the top of my head, we would also need a From impl for std::result::Result so that ? works (because it can't automatically do Result<T, E> into Result<S, F> just because T: Into<S> and E: Into<F>).

I think we get a lot of that for free with thiserror, so if you're not averse to adding that as a dependency, I'll use it. If not, I won't, but there might be extra boilerplate.

[elinorbgr]

I'm fine with using thiserror, but without Box<dyn Error> we cannot allow the event sources to have their own custom error types. I thought that that was what you wanted?

[detly]

Ah I see what you're saying. The significant part for me is not so much "event sources having custom error types" as "having error types that can easily be chained with ? or maintain a traceback through the callbacks." I'm actually not sure how much a boxed error would have to proliferate, so maybe I should code something up and see what's possible?

[elinorbgr]

Ah I see. I don't know how much of a necessity having custom error types for event sources is. But I guess we can still have a fancy calloop error type based on thiserror, which a Custom(Box<dyn Error>) variant for cases where the event source really needs it.