Repository navigation
QuicConnection.ConnectAsync raises SocketException when host not found #78751
Description
Description
The QuicConnect.ConnectAsync method raises a SocketException(SocketErrorCode = HostNotFound) if the resolution of a DnsEndPoint set with QuicClientOptions.RemoteEndpoint fails. I did expect a QuicException with a suitable error code instead.
Reproduction Steps
await using var connection = await QuicConnection.ConnectAsync(new QuicClientConnectionOptions
{
RemoteEndPoint = new DnsEndPoint("bogus.foo.com", 5001);
ClientAuthenticationOptions = new SslClientAuthenticationOptions { ... }
});Expected behavior
A QuicException with suitable QuicError.
Actual behavior
It raises a SocketException.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
Activity
ManickaP commentedon Nov 23, 2022
We have several places where we don't raise
QuicException. Some raiseAuthenticationExceptionfor example. However, it might be unexpected to getSocketException, seemingly System.Net.Sockets exclusive type, from System.Net.Quic.On the other hand, in #76435 we got a feedback that we could leverage
SocketException, albeit as a wrapped exception.Lastly, in #75184, we have another use case that expects us to always wrap in
QuicException.Either way, we have several loosely related issue to exception types and their wrapping. We should take all this feedback and come up with a comprehensive solution to this.
Triage: this should be settled in 8.0.
cc: @rzikm
wfurt commentedon Nov 23, 2022
It seems like we don't document what
ConnectAsynccan throw. We should probably fix that regardless of the choice so callers can handle that properly.alexrp commentedon Nov 24, 2022
Just for the record, that seems to be a pervasive issue with all the QUIC API documentation, not just this particular method.
antonfirsov commentedon Nov 24, 2022
Note that we shouldn't document stored (async) exceptions in the exception section of the API docs - dotnet/dotnet-api-docs#7840 (comment). The fact that we do it for some of the networking API docs is a violation of general BCL API doc practices.
alexrp commentedon Nov 24, 2022
That issue mentions that async APIs should point to sync APIs for the possible exceptions. There are no sync APIs for QUIC at this time, though?
antonfirsov commentedon Nov 24, 2022
Yepp, just pointed it out in the discussion.
ManickaP commentedon Jan 19, 2023
Triage: this is part of bigger revision on exception in Quic. We should address this 8.0.
Slightly related: #75184
wfurt commentedon Jun 30, 2023
We agreed to throw
SocketExceptionfor transport errors - part of #82262 and based on API review feedback.e.g.
QuicExecptionwill indicate erros at Quic layer,SocketExceptionwith indicate problems bellow - e.g. IP or UDP. We shall document that somehow, perhaps as remarks because of pending debate about exceptions thrown synchronously vs exceptions stored in resultingTask.ManickaP commentedon Oct 3, 2023
Closing this in lieu of #92943