2009-03-20 5 views
5

Ho avuto problemi con la gestione degli eventi nei thread di backgroundworker.Gestione degli eventi di background worker

Tutta la documentazione che ho incontrato mi fanno credere che quando un gestore di eventi DoWork genera un'eccezione tale eccezione deve essere affrontato nel gestore RunWorkerCompleted e tale eccezione sarà disponibile nella proprietà errore dei RunWorkerCompletedEventArgs.

Questo va bene, ma durante il tempo di debug vedo sempre un'eccezione non gestita dal messaggio di codice utente. Questo mi fa credere che ci sia un problema con il mio approccio.

Quali operazioni devo intraprendere per risolvere questo problema?

saluti, Jonathan

risposta

2

Ho visto questo comportamento prima, e ho ottenuto intorno ad esso decorando il gestore DoWork con l'attributo System.Diagnostics.DebuggerNonUserCode:

[System.Diagnostics.DebuggerNonUserCode] 
void bw_DoWork(object sender, DoWorkEventArgs e) 
{ ... } 

Nota che vedrai questo solo se stai correndo nel debugger; anche senza l'attributo, tutto è come dovrebbe essere quando si esegue dalla shell.

L'ho cercato di nuovo, e ancora non riesco a vedere alcun motivo valido per cui è necessario farlo. Lo sto definendo una disfunzione del debugger.

+0

Perché è necessario farlo? Perché è come funziona BackgroundWorker. Molto più facile da gestire l'errore nel thread chiamante rispetto al thread di lavoro. Ma quando si esegue il debug, l'altro modo è vero poiché si ottiene l'accesso a tutte le variabili locali. – Samuel

+0

Non penso che "sia così che funziona BackgroundWorker" è una risposta soddisfacente. Sembra che tu veda tutte le eccezioni come indicative di errori di codifica - questo è vero solo a volte. Se volessi che il debugger si interrompesse su un'eccezione gestita, accendere le eccezioni di prima scelta o impostare un punto di interruzione. –

0

Il tuo approccio è corretto. Basta premere continua sul messaggio e andare avanti. In caso di dubbio, testarlo al di fuori di una sessione di debug.

1

Ho avuto questo problema prima. L'errore e.Error viene impostato solo quando non si esegue la modalità di debug. Se si esegue in Debug, l'exectuion si ferma nel punto dell'eccezione. Tuttavia, esegui lo stesso programma in modalità Non debug (in VS Debug -> Avvia senza debug o Ctrl + F5) e la brutta finestra di dialogo delle eccezioni NON si presenterà, ed e.error sarà l'eccezione. Non so perché, ma è così che funziona ....