-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use own error type for API #57
Comments
Yes, definitely. Notably, |
Excellent, we can discuss the general approach here and then I'll code it up. I tend to avoid My first suggestion would be to have a
Off the top of my head, we would also need a I think we get a lot of that for free with |
I'm fine with using |
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 |
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 |
One of the little-but-common annoyances I run into with Calloop is that eg.
process_events()
returns astd::io::Result
, butstd::io::Error
is just about the only Rust error type in existence that doesn't have a single-argument constructor. So I always have to tack on.map_err(|e| std::io::Error::new(std::io::ErrorKind::Other, e))
. This is compounded by the fact that you can use any type you like forEventSource
's associatedRet
, which is usually going to be aResult<T, E> where E: std::error::Error
rather thanstd::io::Error
(precisely becausestd::io::Error
is a pain to use in your own API and arguably is not intended to be).Should Calloop have its own error (and corresponding result) for
process_events()
(and possibly other trait methods onEventSource
? It would be possible to haveFrom
implementations to ensure that?
still works. Then (a) using?
onstd::io::Result
s from fd operations would still be fine, and (b) so would using?
oncore::result::Result
oranyhow::Result
or errors fromthiserror
etc.I would be happy to make such a change, but it is potentially a breaking one so I wanted to see if it's something you'd be open to.
The text was updated successfully, but these errors were encountered: