Open yuriykulikov opened 2 years ago
Hey, thanks for raising this. There is already similar opened issue #148.
Im now in progress of rewriting transport API to support QUIC, and I will try to solve this unexpected error
in some way to not clutter users with such errors.
Same thing happens on the server-side when a client disconnects.
Motivation
As of
0.15.4
, when the client loses the connection to the server, a ClosedReceiveChannelException is thrown in one of the client coroutines. It is propagated to the CoroutineExceptionHandler and is printed. It looks like this (using TcpClientTransport):Desired solution
In my opinion, this exception can be supressed, because if the channel is closed, the client cannot do anything about it and should just quit or reconnect. This can be achieved by attaching a
CoroutineExceptionHandler
to theTcpConnection
coroutineContext
:Considered alternatives
An alternative would be to catch the exception close to the
readPacket
invokation, but doing so breaks the responderrSocket
coroutineScope
behavior. For example, if client code relies on the scope cancellation to log disconnects, this cancellation won't happen.Additional context
Exception is usually thrown when reading packet length: