You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently too many variants in reactor::Error, which makes the crate very hard to use, as it's unclear how each of these errors should be handled. Ideally most of the variants have clear actionables, eg. unregistering the socket. Here's what I'd start with.
These errors come from improper use of the API by the user, and shouldn't be reactor errors.
If we're trying to unregister an unknown peer, not returning an error makes unregistering idempotent,
which makes the API easier to use. If we're trying to write to an unknown peer, we could return a WriteFailure error instead. Since they aren't fatal and can easily happen due to race conditions, I'd simply log an error
and remove the variants:
These are pretty critical and it's not clear how they can happen, but if our listener socket goes
down, we probably want to restart the node. I would probably merge the two variants into Error::ListenerFailed,
since there isn't really a difference in how they should be handled.
This error should be whatever the internal Poll implementation returns. Ideally it can be downcasted to the
concrete error type. Poll errors should be fatal, so we'd probably abort here.
reactor::Error::Poll(err)
I'm guessing this one is a clean disconnect, in which case we can handle it and unregister the socket:
reactor::Error::TransportDisconnect(id, _, err)
These two seem like they can be bundled under Error::Transport, since they'd likely both be handled by
disconnecting:
is that *Disconnect variants unregister resource from the reactor automatically, while *PollError do not. My assumption was that disconnect is permanent while PollError or write errors may be temporary
Not sure this is a best strategy, but it was a reason for having distinct error types
There are currently too many variants in
reactor::Error
, which makes the crate very hard to use, as it's unclear how each of these errors should be handled. Ideally most of the variants have clear actionables, eg. unregistering the socket. Here's what I'd start with.These errors come from improper use of the API by the user, and shouldn't be reactor errors.
If we're trying to unregister an unknown peer, not returning an error makes unregistering idempotent,
which makes the API easier to use. If we're trying to write to an unknown peer, we could return a
WriteFailure
error instead. Since they aren't fatal and can easily happen due to race conditions, I'd simply log an errorand remove the variants:
These are pretty critical and it's not clear how they can happen, but if our listener socket goes
down, we probably want to restart the node. I would probably merge the two variants into
Error::ListenerFailed
,since there isn't really a difference in how they should be handled.
This error should be whatever the internal
Poll
implementation returns. Ideally it can be downcasted to theconcrete error type. Poll errors should be fatal, so we'd probably abort here.
I'm guessing this one is a clean disconnect, in which case we can handle it and unregister the socket:
These two seem like they can be bundled under
Error::Transport
, since they'd likely both be handled bydisconnecting:
The text was updated successfully, but these errors were encountered: