Why is Visual Studio skipping over my Exception from a ThreadPool work item?

Question

I am aware of this other post, but it doesn't seem to apply to my situation.

First off, here is my environment:
Windows XP 64-bit SP3; Visual Studio 2008 w/ SP; .NET 3.5 SP1; WPF application.

My problem is that I cannot seem to step to where my exception happens. It just keeps running instead of continuing the debugging session.

Here is some code -- I didn't write all of it, so please, no need for comments on naming :)

// start up the WPF application
// set the handler for the Checked event
ToggleButton channelButton1 = new ToggleButton();
channelButton1.Checked += (s, e) => 
     ThreadPool.QueueUserWorkItem(SetTcpChannel, 1);

Then in that SetTcpChannel method:

    try
    {
        int channel = (int)state;
        EnsureTcpSocket();
        // more logic to do stuff with channel 
        // that we don't care about for SO
        ...
    }
    catch (Exception e)
    {
        // just for illustration
        // this is where I expected the code to return
        ...
    }

And finally, in the place where the exception actually happens (inside EnsureTcpSocket):

    if (_tcp == null)
    {
        // this is not a valid ip/port since the 
        // target machine is not running (test condition)
        // but that's ok, I should get some exception 
        // and continue debugging...right?
        _tcp = new TcpClient(ip, port);
    }

Here is what I have been doing:

1. I set a breakpoint at the EnsureTcpSocket line inside SetTcpChannel,
2. F11 (step-into) EnsureTcpSocket so I can see the _tcp piece of code
3. Try to F10 (step-over) the TcpClient constructor

At that last step, the application comes back up from the debugger and keeps running and I never see any exception.

Any ideas?

Answer 1

How long did you wait? Depending on exactly what the arguments are, the TcpClient constructor may wait until it times out before throwing the exception. (If the connection is refused, that's a different matter.)

Answer 2

Do you have a breakpoint inside the catch block, if not I don't see why the debugger would break the execution and stop there?

Alternatively, in Visual Studio you can set debugging options to break on First Chance exceptions, here's an old post that describes how.