TcpClient.Connect causes three first chance exceptions

[illegal.prime]

Hi all, I've got a client/server application and just wanted to ensure
that this is expected behavior. I recently set the following
configuration in Visual Studio:
Debug->Exceptions->Break Into Debugger
for the CLR Exceptions

And when my debugger hits the TcpClient.Connect statement and the
server is not available - I get the following three first chance
exceptions:
A first chance exception of type 'System.Net.Sockets.SocketException'
occurred in system.dll

Additional information: The requested name is valid and was found in
the database, but it does not have the correct associated data being
resolved for
----------------
A first chance exception of type 'System.Net.Sockets.SocketException'
occurred in system.dll

Additional information: A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond
----------------
A first chance exception of type 'System.Net.Sockets.SocketException'
occurred in system.dll

Additional information: A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond
----------------

I handle the exception and my code continues on its merry way - I just
wanted to see if anyone could provide some insight on this.

Thanks,
Novice

 

[Daniel]

A socket exception when the server is not available is normal yes.

 

[illegal.prime]

I handle the socket exception that is eventually thrown - but that
single method actually causes three first chance exceptions (one of
which is the one it eventually throws and which I handle).

 

[Daniel]

When the server is available, do you get these exceptions?

 

[illegal.prime]

Hey there - I guess I wasn't clear in my original post. I fully
expected and handle getting an exception thrown (when the server is
unavailable). I was just surprised by getting three first chance
exceptions. The first one looks like the name lookup in the DNS server
fails and then the other two look slightly redudant.

I guess I just wanted clarification on those three first chance
exceptions that are thrown from within the Connect method (the last of
which is the one I handle).

Novice

 

[Daniel]

Well if your server isnt available chances are it tries doing its connection
logic and goes oops i cant do this, and oops i cant do that either etc etc.

I'd only be concerned if when you connect successfully you get excpetions.
If you don't then don't worry about it

 

[Damien]

Hey there - I guess I wasn't clear in my original post. I fully
expected and handle getting an exception thrown (when the server is
unavailable). I was just surprised by getting three first chance
exceptions. The first one looks like the name lookup in the DNS server
fails and then the other two look slightly redudant.

I guess I just wanted clarification on those three first chance
exceptions that are thrown from within the Connect method (the last of
which is the one I handle).

Novice

Hi,

You've chosen to look at all first chance exceptions, not just all
unhandled exceptions. The first two are being handled somewhere in the
framework, obviously. You'd be surprised how many exceptions the
framework can throw (I thought I'd seriously crippled an ASP.Net
program where it would only start debugging without throwing an
exception about 1 in 5 times. Then I remembered that I'd turned on
break on all first chance exceptions).

I guess the question in my mind is why you've chosen to inspect all
first chance exceptions, and why you think these exceptions should be a
matter of concern. Is it idle curiosity (which I certainly always
welcome, but I'm not going to necessarily go hunting myself for
explanations) or are you encountering a problem and trying to
understand the underlying cause (in which case I may go exploring,
which I enjoy doing sometimes). If it's the second case, it may be more
worthwhile explaining what your initial area of concern is, rather than
this current rather narrowly focussed debugging attempt.

Damien

 

[illegal.prime]

The reason I'm wondering about it is because:
1. This connect attempt and eventual failure takes about 5-10 seconds -
I want to know why.
2. I also wonder if there is a configuration I can give to the
TcpClient (perhaps in its constructor or using an overloaded version of
the Connect method) to make it operate more efficiently. A good
example is that because of the first chance exceptions I know part of
that time is being spent doing a name-lookup. If I use the raw IP
Address I could avoid that cost.

Novice