Exceções de Threads gerenciados
No.NET Framework versão 2.0, o common language runtime permite mais exceções sem tratamento em threads para prosseguir naturalmente. Na maioria dos casos, isso significa que a exceção não tratada faz com que o aplicativo seja finalizado.
Observação
Essa é uma alteração significativa da.NET Framework versões 1.0 e 1.1, que fornecem uma barreira para muitas exceções não tratadas — por exemplo, exceções não tratadas em threads do pool.Consulte alteração das versões anteriores posteriormente neste tópico.
O common language runtime fornece um exceções de barreira para determinados sem tratamento são usados para controlar o fluxo de programa:
A ThreadAbortException é lançada em um thread porque Abort foi chamado.
Um AppDomainUnloadedException é lançada em um thread porque o domínio de aplicativo no qual o thread está em execução está sendo descarregado.
O common language runtime ou um processo de host encerra o thread lançando uma exceção interna.
Se qualquer uma dessas exceções são sem tratamento em threads criados pelo common language runtime, a exceção encerra o thread, mas o common language runtime não permite que a exceção prosseguir.
Se essas exceções sem tratamento no thread principal ou em segmentos que inseriu o tempo de execução do código não gerenciado, prossegue normalmente, resultando no encerramento do aplicativo.
Observação
É possível para o runtime lançar uma exceção não tratada antes de qualquer código gerenciado tenha tido a oportunidade de instalar um manipulador de exceção.Embora o código gerenciado teve a chance de lidar com tal exceção, a exceção é permitida para prosseguir naturalmente.
Expondo Threading problemas durante o desenvolvimento
Quando os threads têm permissão para falhar silenciosamente, sem encerrar o aplicativo sérios problemas de programação podem ser detectados. Este é um problema específico para serviços e outros aplicativos que são executados por períodos prolongados. Como threads falhar, o estado de programa gradualmente danificado. Pode degradar o desempenho do aplicativo ou o aplicativo pode travar.
Permitir exceções sem tratamento em threads para prosseguir, naturalmente, até que o sistema operacional encerra o programa expõe tais problemas durante o desenvolvimento e teste. Relatórios de erro sobre depuração de suporte de encerramentos de programa.
Alterar a partir de versões anteriores
A alteração mais significativa pertence para threads gerenciados. No.NET Framework versões 1.0 e 1.1, o common language runtime fornece uma barreira para exceções não tratadas nas seguintes situações:
Não há nenhum algo como uma exceção não tratada em um thread do pool. Quando uma tarefa lança uma exceção que não manipula, o runtime imprime o rastreamento de pilha de exceção para o console e, em seguida, retorna o thread ao pool de segmentos.
Existe nenhuma exceção não tratada em um segmento é criado com o Start método de Thread classe. Quando o código em execução em tal thread lança uma exceção que não manipula, o tempo de execução imprime o rastreamento de pilha de exceção para o console e, em seguida, normalmente termina o segmento.
Não há nenhum algo como uma exceção não tratada no thread do finalizador. Quando um finalizador lança uma exceção que não manipula, o runtime imprime o rastreamento de pilha de exceção para o console e permite que o thread do finalizador continuar a execução de finalizadores.
O status de primeiro plano ou plano de fundo de um thread gerenciado não afeta este comportamento.
Para exceções sem tratamento em threads originado em código não gerenciado, a diferença é mais sutil. A caixa de diálogo anexar o JIT do runtime ocupa a caixa de diálogo do sistema operacional para exceções gerenciadas ou exceções nativas em segmentos que passaram por código nativo. O processo termina em todos os casos.
Migrando o código
Em geral, a alteração irá expor problemas anteriormente não reconhecidos de programação para que possam ser corrigidos. Em alguns casos, entretanto, os programadores podem tiramos proveito de barreira de tempo de execução, por exemplo, para encerrar segmentos. Dependendo da situação, eles devem considerar uma das seguintes estratégias de migração:
Reestruture o código para que o segmento é encerrado normalmente quando um sinal.
Use o Thread.Abort método para abortar a thread.
Se um segmento deve ser parado para que possa continuar o encerramento do processo, verifique o thread de um segmento de plano de fundo para que ela é finalizada automaticamente ao sair do processo.
Em todos os casos, a estratégia deve seguir as diretrizes de design para exceções. Consulte Diretrizes de design para exceções.
Sinalizador de compatibilidade do aplicativo
Como uma medida temporária de compatibilidade, os administradores podem colocar em um sinalizador de compatibilidade de <runtime> seção do arquivo de configuração do aplicativo. Isso faz com que o common language runtime reverter para o comportamento das versões 1.0 e 1.1.
<legacyUnhandledExceptionPolicy enabled="1"/>
Substituição de host
No.NET Framework versão 2.0, um host não gerenciado pode usar o ICLRPolicyManager interface na API de hospedagem para substituir o padrão sem tratamento a política de exceções do common language runtime. O ICLRPolicyManager:: SetUnhandledExceptionPolicy função é usada para definir a diretiva para exceções não tratadas.