Consider throwing something other than TaskCanceledException on outstanding requests when remote end closes stream about vs-streamjsonrpc HOT 4 CLOSED

I am not like strongly against the cancellation exception. but I would normally expect cancellation exception from the cancellation token I gave in. if I get random cancellation exception, I will be like what did I cancel?

if I get like UnexcpectedDisconnectionException with message saying, someone Closed or Disposed JsonRpc/Underlying Stream while InvokeAsync is active, then it is more clear why the exception happened.

from vs-streamjsonrpc.

@heejaechang has this been a problem for you with Roslyn? Otherwise I may won't fix this.

from vs-streamjsonrpc.

@AArnott is there a specific reason why it chose to throw cancellation exception rather than explicit exception like unexpected disconnection or something like that?

from vs-streamjsonrpc.

A few reasons:

1. It was the simplest approach: the only way the code had to interrupt the task we returned earlier is to cancel it.
2. Given this is truly an exceptional situation, if we were to throw a novel exception type, we run the risk of the client not expecting to need to catch and deal with it. But it's quite likely they have a catch block around the call.
3. Does the client really need to distinguish from all these events? Or ultimately will it handle them all the same? There already is a way for the client connection owner to receive an event about an unexpected connection closure, so that it could (for example) reconnect. But surely you wouldn't want every single outstanding request to receive an exception and each try to reestablish the connection at once.

That said, we do already define a RemoteRpcException base class, from which we could derive a more specific exception type. The client should (hopefully) already be prepared to catch this base exception type, so throwing a new derived type should have a relatively low risk.

from vs-streamjsonrpc.