Perché Visual Studio saltando sopra la mia eccezione da un elemento di lavoro ThreadPool?

Question

Sono a conoscenza di questo altro posta , ma non sembra applicare alla mia situazione.

Prima di tutto, ecco il mio ambiente:
Windows XP 64-bit SP3; Visual Studio 2008 w / SP; NET 3.5 SP1; un'applicazione WPF.

Il mio problema è che io non riesco a passo per cui il mio un'eccezione accade. Si continua a correre invece di continuare la sessione di debug.

Ecco il codice - Non l'ho scritto tutto questo, quindi per favore, senza bisogno di commenti su di denominazione:)

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

Poi, in quel metodo SetTcpChannel:

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

E, infine, nel luogo in cui l'eccezione che effettivamente accade (all'interno 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);
    }

Ecco quello che ho fatto:

1. I impostare un punto di interruzione alla linea EnsureTcpSocket all'interno SetTcpChannel,
2. F11 (step-in) EnsureTcpSocket così posso vedere il pezzo di _tcp codice
3. Prova a F10 (step-over) il costruttore TcpClient

A questo ultimo passo, l'applicazione viene sostegno dal debugger e mantiene in esecuzione e non ho mai vedere alcuna eccezione.

Tutte le idee?

Answer 1

Per quanto tempo hai aspettato? A seconda esattamente ciò che gli argomenti sono, il costruttore TcpClient può aspettare fino a quando il tempo è scaduto prima di gettare l'eccezione. (Se la connessione viene rifiutata, questo è un altro discorso.)

Answer 2

Avete un punto di interruzione all'interno del blocco catch, se non non vedo il motivo per cui il debugger si romperebbe l'esecuzione e fermarsi qui?

In alternativa, in Visual Studio è possibile impostare le opzioni di debug per rompere sulle eccezioni prima occasione, ecco un vecchio post che descrive come .