CLR si chiude quando un'eccezione viene gestita da un thread

Question

Ho thread in background nella mia applicazione. Quando uno dei thread riceve un'eccezione che non viene gestita, l'intero CLR viene chiuso.

È un comportamento normale o un bug nel CLR?

Mi aspetto che il thread venga chiuso ma il CLR continuerà a funzionare.

Answer 1

È un comportamento normale. Forse vuoi catturare l'eccezione per evitare che l'applicazione esca.

Answer 2

sì, è normale e si può vedere questo simile question per maggiori dettagli.

Answer 3

Questo è un comportamento normale del CLR dalla v2.0. Ecco un post MSDN su questo. Per evitare di interrompere il processo, è possibile utilizzare qualcosa come

<legacyUnhandledExceptionPolicy enabled="1"/> 

che non è consigliabile.

Answer 4

Il comportamento previsto era il comportamento riportato in 1.1. È stata generalmente considerata una cattiva idea. Quando si ha un'eccezione non gestita in qualsiasi thread, il processo può essere lasciato in uno stato incoerente. Gli aggiornamenti ai dati condivisi possono essere parzialmente applicati, ecc. Il runtime non ha le informazioni per gestire in sicurezza questo scenario, o anche sapere come si vuole gestire questo scenario, quindi la sua scelta equivarrebbe a terminare il thread e lasciare il programma in uno strano stato. Ciò potrebbe portare a perdite di risorse, blocchi, corruzione dei dati, ecc. Terminando il processo dato un'eccezione non gestita si sa esattamente cosa succede, il processo finisce.

Answer 5

Il comportamento predefinito nelle applicazioni .NET è di uscire ogni volta che si verifica un'eccezione non gestita. Quando un'eccezione non viene gestita, il programma si trova in uno stato sconosciuto e forse instabile. Solo perché è accaduto in un thread in background non significa che l'errore non influenzerà il resto del programma. Il corso più prudente per il runtime in quella situazione è scaricare il programma.

È possibile esaminare AppDomain.CurrentDomain.UnhandledException, che consente di rilevare eccezioni non gestite e reagire di conseguenza. Una soluzione migliore è quella di avvolgere il tuo thread proc con un try...catch. Ma ha solo gestire le eccezioni che sa come gestire. In questo modo:

void MyThreadProc() 
{ 
    try 
    { 
     // ... 
    } 
    catch 
    { 
     // handle all exceptions 
     // This is a BAD idea 
    } 
} 

è una pessima idea, perché può mascherare le eccezioni che davvero si desidera essere propagate al programma principale.