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
As discussed in #213 and #214, it is proposed to make sure node request handlers catch all exceptions and notify the client that there was an error. (i.e. request handlers should never throw.)
This can be implemented on the swarm level in the following way:
On the node side, catch the exceptions and send the message to the client with the different MessageType - so that the client doesn't need to be always registered for receiving error messages. However, as Handling of I/O exceptions in node request handlers #216 states, we shouldn't catch IOErrorin the RequestOnConn's fiber handler method, since the client will anyway be notified by the connection dropping.
On the client side, it's an open question how this message will be handled, since the notifiers are handled by the request, not by the connection handler in swarm. One possibility would be just to resume the request fiber with an exception, but that requires try/catch behaviour on the client side.
The text was updated successfully, but these errors were encountered:
As discussed in #213 and #214, it is proposed to make sure node request handlers catch all exceptions and notify the client that there was an error. (i.e. request handlers should never throw.)
This can be implemented on the swarm level in the following way:
On the node side, catch the exceptions and send the message to the client with the different
MessageType
- so that the client doesn't need to be always registered for receiving error messages. However, as Handling of I/O exceptions in node request handlers #216 states, we shouldn't catchIOError
in the RequestOnConn's fiber handler method, since the client will anyway be notified by the connection dropping.On the client side, it's an open question how this message will be handled, since the notifiers are handled by the request, not by the connection handler in swarm. One possibility would be just to resume the request fiber with an exception, but that requires
try/catch
behaviour on the client side.The text was updated successfully, but these errors were encountered: