1

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?

Community
  • 1
  • 1
Erich Mirabal
  • 9,860
  • 3
  • 34
  • 39

2 Answers2

2

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.)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Doh! I had waited for a little, but obviously forgot to wait for the TCP timeout period. I had kept closing it down before it got around to throwing the actual exception. – Erich Mirabal Apr 28 '09 at 18:58
  • Gosh - I hardly expected that to actually be the reason. I thought it was worth mentioning just in case :) – Jon Skeet Apr 28 '09 at 19:00
  • Honestly, I feel like I should shed some rep for that. SO should have a "flagellate yourself" option when you realize that you did something very dumb. – Erich Mirabal Apr 28 '09 at 19:01
  • Psychic debugging at it's best :) – Sijin Apr 28 '09 at 19:01
  • @Erich: None of us would have any rep left. – Jon Skeet Apr 28 '09 at 19:02
  • @Erich Mirabal, we all probably spend too much time on the "very dumb" errors. If we didn't have the "dumb errors" to account for, then task estimation would actually be a useful practice. Don't sweat it, that's what the community is all about. :) – Michael Meadows Apr 28 '09 at 19:07
1

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.

Sijin
  • 4,530
  • 21
  • 22