Fix exception catch block in Dispose_CancelsConnectAsync test

[stephentoub]

Fixes #35886

[ghost]

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[davidsh]

#35886 was a test failure where the exception was "System.Net.Sockets.SocketException : Bad value for ai_flags".

Is that an "expected" exception side-affect from this test? It almost looks like a programming error.

[stephentoub]

Is that an "expected" exception side-affect from this test? It almost looks like a programming error.

This is disposing in the middle of a connect. My assumption is that pretty much any socket exception could occur as a result. Let me know if you think it's actually a concern.

[davidsh]

This is disposing in the middle of a connect. My assumption is that pretty much any socket exception could occur as a result. Let me know if you think it's actually a concern.

I do think it is a concern. If it was something like "connection error" etc., that would make more sense with it being a race condition of disposing during connection.

But this exception looks suspect. I think someone more knowledgable about System.Net.Sockets should comment on this.

Basically, I worry that there is some regression in Sockets potentially due to all the recent code churn.

@wfurt @tmds @scalablecory @antonfirsov

[scalablecory]

I think catching all SocketException is too broad and will cover up bugs.

The exception message in the issue points to getaddrinfo misuse or maybe a bad error code being generated somewhere, not to a dispose-related error:

System.Net.Sockets.SocketException : Bad value for ai_flags

I agree with @davidsh this needs a closer look.

[stephentoub]

System.Net.Sockets.SocketException : Bad value for ai_flags

This is what new SocketException((int)SocketError.SocketError) currently produces. SocketError.SocketError is -1, which is the same value as EAI_BADFLAGS on Linux.

[stephentoub]

I think catching all SocketException is too broad and will cover up bugs.

Ok