A API de criação de perfil de manipulação de exceção
Notificações de exceção são mais difíceis de todas as notificações para descrever e compreender. Este tópico descreve o processamento de exceção e explica como a API de criação de perfil trata vários tipos de exceções.
Fluxograma de notificação de exceção
Processamento de exceção é inerentemente complexo. As notificações de exceção descritas neste tópico fornecem todas as informações que requer um gerador de perfil sofisticado para acompanhar a passagem (fase de pesquisa ou desenrolar fase), o quadro, o filtere o finally block, que é executada para cada thread no processo perfilado. Notificações de exceção não fornecerá nenhum ThreadIDs, mas você pode chamar o ICorProfilerInfo::GetCurrentThreadID método para descobrir qual thread gerenciado lançou a exceção.
A ilustração a seguir mostra como o criador de perfil de código recebe vários retornos de chamada, quando ele monitora eventos de exceção. Cada segmento começa no estado de execução normal. Quando o thread está em um estado dentro do sistema de exceção (na pesquisa de fase ou desenrolar fase), ela é controlada pelo sistema de exceção. Os retornos de chamada relacionados à exceção (por exemplo, ICorProfilerCallback::ObjectAllocated) que ocorrem enquanto o thread está em um desses estados podem ser atribuídos para o sistema de exceção. Quando o thread está em um estado fora do sistema de exceção, ele executa o código gerenciado arbitrário.
Sequência de retorno de chamada de exceções
.png "Sequência de retorno de chamada de exceções")
.png "Sequência de retorno de chamada de exceções")
Exceções aninhadas
Threads cruzou o código gerenciado, durante o processamento de exceção poderiam lançar outra exceção, o que resultaria em uma passagem inteiramente nova de manipulação de exceção. (Essa nova passagem é indicada por "Nova tratamento de exceção pass" na ilustração anterior.) Se uma exceção aninhada expõe a filter/finally/catch blocos de exceção original, esse pode afetam a exceção original da seguinte maneira:
Se ocorreu a exceção aninhada em um filter bloco e escapa a filter bloco, o filter serão consideradas para retornar false e continuará a primeira passagem.
Se ocorreu a exceção aninhada em um finally bloco e escapa a finally bloco, processamento da exceção original será nunca resume.
Se ocorreu a exceção aninhada em um catch bloco e escapa a catch bloco, processamento da exceção original será nunca resume.
Manipuladores não gerenciados
Uma exceção pode ser tratada em código não gerenciado. Nesse caso, o profiler verá a fase de desenrolamento, mas não receberão a notificação de catch manipuladores. Execução apenas continuará normalmente no código não gerenciado. Um gerador de perfil que está ciente do código não gerenciado, conseguirá detectar essa situação, mas um gerador de perfil gerenciado somente pode ver várias coisas, incluindo mas não limitado à seguinte:
Um ICorProfilerCallback::UnmanagedToManagedTransition código de retorno de chamada quando o código não gerenciado chama ou retorna a gerenciado.
Finalização do thread (se o código não gerenciado estava na raiz do segmento).
Encerramento de aplicativo (se o código não gerenciado encerra o aplicativo).
Manipuladores CLR
Uma exceção pode ser tratada pelo common language runtime (CLR) propriamente dito. Nesse caso, o profiler verá a fase de desenrolamento, mas não receberão a notificação de catch manipuladores. Ele pode ver a execução é reiniciado normalmente no código gerenciado ou não gerenciado.
Exceções Não Tratadas
Por padrão, uma exceção não tratada levará para processar o encerramento na.NET Framework versão 2.0. Você pode forçar a conformidade com o.Diretiva de exceção do NET Framework versão 1 usando um sinalizador de compatibilidade do aplicativo, conforme descrito em Exceções de Threads gerenciados.