QUIC: Standardize exception meaning and behavior

[geoffkizer]

I was talking with @JamesNK today about this. He's trying to figure out what exceptions can be thrown from what methods in what circumstances.

I think we need to
(a) Clarify exception meaning and usage
(b) Document what exceptions can happen when
(c) Ensure we have tests that validate this behavior.

Here's my quick attempt to define things as I understand them, please add/comment:

QuicStreamAbortedException should happen when the peer has aborted the stream (and we should always have an error code)
QuicConnectionAbortedException should happen when the peer has aborted the connection (and we should always have an error code)
QuicOperationAbortedException should happen when you do something that results in a local operation being aborted, e.g. AbortRead (or close Stream or close Connection) with a pending Read
OperationCanceledException should happen when the cancellation token for a particular call fires, and it should always contain the relevant cancellation token
ObjectDisposedException should happen when the object is disposed or closed (with a few exception, like calling dispose again)
TBD: What should happen when “shutdown by transport” occurs? In this case, the connection is dead but we have no error code to report.
TBD: What should happen if you try to e.g. Read after AbortRead, or Write after AbortWrite, or Write after CompleteWrites?
TBD: What should happen if you call AbortRead when read is already aborted, either locally or by peer? Similarly for AbortWrite and CompleteWrites
TBD: Exception behavior for other methods, e.g. AcceptStream/Connection, WaitForAvailableStreams, etc.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I was talking with @JamesNK today about this. He's trying to figure out what exceptions can be thrown from what methods in what circumstances.

I think we need to
(a) Clarify exception meaning and usage
(b) Document what exceptions can happen when
(c) Ensure we have tests that validate this behavior.

Here's my quick attempt to define things as I understand them, please add/comment:

QuicStreamAbortedException should happen when the peer has aborted the stream (and we should always have an error code)
QuicConnectionAbortedException should happen when the peer has aborted the connection (and we should always have an error code)
QuicOperationAbortedException should happen when you do something that results in a local operation being aborted, e.g. AbortRead (or close Stream or close Connection) with a pending Read
OperationCanceledException should happen when the cancellation token for a particular call fires, and it should always contain the relevant cancellation token
ObjectDisposedException should happen when the object is disposed or closed (with a few exception, like calling dispose again)
TBD: What should happen when “shutdown by transport” occurs? In this case, the connection is dead but we have no error code to report.
TBD: What should happen if you try to e.g. Read after AbortRead, or Write after AbortWrite, or Write after CompleteWrites?
TBD: What should happen if you call AbortRead when read is already aborted, either locally or by peer? Similarly for AbortWrite and CompleteWrites
TBD: Exception behavior for other methods, e.g. AcceptStream/Connection, WaitForAvailableStreams, etc.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	6.0.0

[karelz]

Triage: We should at least have a plan in 6.0, then see if there is work which must-have for 6.0.

[rzikm]

Fixed by #70669.