Exceptions from QUIC APIs should derive from IOException

[geoffkizer]

For one, exceptions from streams usually derive from IOException and QuicStream should follow this.

But it also seems reasonable and consistent to have exceptions from QuicConnection/QuicListener derive from IOException as well. In particular, some exceptions are used for both QuicStream and QuicConnection.

Related: #56292 (comment)

[ghost]

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

Issue Details

---

For one, exceptions from streams usually derive from IOException and QuicStream should follow this.

But it also seems reasonable and consistent to have exceptions from QuicConnection/QuicListener derive from IOException as well. In particular, some exceptions are used for both QuicStream and QuicConnection.

Related: #56292 (comment)

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

[GSPP]

Precedent is mostly that IOException is not being used as a base class. Rather, QuicException should be caught by calling code.

[geoffkizer]

The problem is that QuicStream derives from Stream, and in general Stream throws IOException. So at least for QuicStream, it seems like we should derive from IOException. so that code that is operating on a generic Stream can at least distinguish IOExceptions from other exceptions.

That said, I don't know how consistent we are about this in general with Stream. Maybe it's not worth it. @stephentoub thoughts?

[stephentoub]

I think it's fine to derive from IOException, though we can discuss it with API review when all of this comes through. There's a lot of antiquated exception derivation stemming from decisions 20 years ago, e.g. the closest existing counterpart to QuicException is probably SocketException, but we're obviously not going to make QuicException derive from Win32Exception or SystemException. There are plenty of exceptions that derive from IOException, and it is what's propagated from types like NetworkStream.

[nibanks]

What about any exceptions/errors related to invalid parameters? TLS/security/crypto related errors? I'm not sure all QUIC errors should be considered IOExceptions necessarily. But I guess it's more of a question: Does the base class of an exception reflect the type of exception or source of exception?

[ManickaP]

Closing as covered by #70669