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
When an exception occurs inside handleConnected, it's re-raised inside _handleData and then caught again inside the main serveForever loop.
The connection is then silently closed (no traceback is shown) so this can make it tricky to find the culprit of a misbehaved websocket. My sense would be to replace instances of raise Exception("Some websocketty thing") with raise WebSocketException("Some websocketty thing") so that they can be explicitly caught in the top-level select loop, and implementors of the WebSocket class will find their code crashing early and often 😬
I'd send a pull request, but I'm not sure I fully grok all the avenues of control flow wherein it would be advantageous to do something different, nor am I equipped to test it 😕
The text was updated successfully, but these errors were encountered:
When an exception occurs inside
handleConnected
, it's re-raised inside_handleData
and then caught again inside the mainserveForever
loop.The connection is then silently closed (no traceback is shown) so this can make it tricky to find the culprit of a misbehaved websocket. My sense would be to replace instances of
raise Exception("Some websocketty thing")
withraise WebSocketException("Some websocketty thing")
so that they can be explicitly caught in the top-level select loop, and implementors of theWebSocket
class will find their code crashing early and often 😬I'd send a pull request, but I'm not sure I fully grok all the avenues of control flow wherein it would be advantageous to do something different, nor am I equipped to test it 😕
The text was updated successfully, but these errors were encountered: