Handler Exceção não tratada no .NET 1.1

votos
23

Estou mantendo um aplicativo .NET 1.1 e uma das coisas que eu fui encarregado de é ter certeza que o usuário não ver as notificações de erro hostis.

Eu adicionei manipuladores para Application.ThreadExceptione AppDomain.CurrentDomain.UnhandledException, que não são chamados. Meu problema é que o diálogo de erro CLR padrão ainda é exibido (antes do manipulador de exceção é chamado).

Jeff fala sobre este problema em seu blog aqui e aqui . Mas não há nenhuma solução. Então, qual é a maneira padrão do .NET 1.1 para lidar com exceções.Ele e exibir uma caixa de diálogo amigável?

A resposta de Jeff foi marcado como a resposta correta, porque a ligação que ele forneceu tem a informação mais completa sobre como fazer o que é necessário.

Publicado 04/08/2008 em 02:15
fonte usuário
Em outras línguas...                            


5 respostas

votos
11

Oh, no Windows Forms você definitivamente deve ser capaz de fazê-lo funcionar. A única coisa que você tem que observar é coisas que acontecem em diferentes threads.

Eu tenho um artigo antigo projeto de código aqui que deve ajudar:

Usuário Manipulação de exceção amigável

Respondeu 04/08/2008 em 05:31
fonte usuário

votos
5

comportamento de exceção não tratada em um 1.x NET aplicativo Windows Forms depende:

  • O tipo de fio que jogou a excepção
  • Se ocorreu durante o processamento de mensagens janela
  • Se um depurador foi ligada ao processo de
  • A configuração de registro DbgJitDebugLaunchSetting
  • A bandeira jitDebugging em App.Config
  • Se você cancelou o Windows Forms manipulador de exceção
  • Se você lidou com evento de exceção do CLR
  • A fase da Lua

O comportamento padrão de exceções não tratadas é:

  • Se a exceção ocorre no segmento principal quando o bombeamento mensagens de janela, ele é interceptado pelo manipulador de formulários exceção do Windows.
  • Se a exceção ocorre no segmento principal quando o bombeamento mensagens de janela, ele irá terminar o processo de aplicativo a menos que seja interceptado pelo manipulador de formulários exceção do Windows.
  • Se a exceção ocorre em um manual, threadpool ou segmento finalizador, é engolido pelo CLR.

Os pontos de contato para uma exceção não tratada são:

  • Windows Forms manipulador de exceção.
  • O registro JIT-debug mudar DbgJitDebugLaunchSetting.
  • O evento exceção não tratada CLR.

O Windows Form tratamento de exceção built-in faz o seguinte por padrão:

  • Pega uma exceção sem tratamento quando:
    • exceção é no segmento principal e nenhum depurador anexado.
    • excepção ocorre durante o processamento da mensagem de janela.
    • jitDebugging = false na App.Config.
  • Mostra uma janela para o usuário e previne a rescisão aplicativo.

Você pode desativar o último comportamento, definindo jitDebugging = true no App.Config. Mas lembre-se que esta pode ser sua última chance de parar de encerramento do aplicativo. Então, o próximo passo para pegar uma exceção não tratada é registrar para Application.ThreadException evento, por exemplo:

Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);

Observe a configuração DbgJitDebugLaunchSetting em HKEY_LOCAL_MACHINE \ Software.NetFramework registro. Isto tem um dos três valores de que eu estou ciente:

  • 0: mostra de diálogo usuário pedindo "debug ou encerrar".
  • 1: permite exceção através de CLR de lidar.
  • 2: lança depurador especificado no DbgManagedDebugger chave de registro.

Em Visual Studio, vá ao menu FerramentasOpçõesDepuraçãoJIT para definir essa chave para 0 ou 2. Mas um valor de 1 é geralmente melhor na máquina de um usuário final. Note que esta chave de registro seja cumprida antes do evento de exceção não tratada CLR.

Este último evento é sua última chance para registrar uma exceção não tratada. Ele é acionado antes de seus blocos finally ter executado. Você pode interceptar este evento como segue:

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);
Respondeu 20/09/2008 em 16:52
fonte usuário

votos
4

AppDomain.UnhandledException é um evento , não um manipulador de exceção global. Isso significa, no momento em que é levantada, a sua aplicação já está a caminho para o ralo, e não há nada que você possa fazer sobre isso, exceto para fazer o registo de limpeza e erro.

O que aconteceu nos bastidores é esta: O quadro detectada a exceção, caminhou até a pilha de chamadas para o topo, não encontrou manipuladores que iria recuperar do erro, por isso foi incapaz de determinar se era seguro continuar a execução. Assim, iniciou-se a sequência de encerramento, e despediu-se este evento como uma cortesia para que você possa pagar seus respeitos a seu processo já condenado. Isso acontece quando uma exceção é deixado sem tratamento no thread principal.

Não há uma solução de ponto único para esse tipo de erro. Você precisa colocar um manipulador de exceção real (um bloco catch) a montante de todos os lugares onde ocorre esse erro e transmiti-la (por exemplo) a global método de manipulador / classe que irá determinar se ele é seguro para simplesmente relatar e continuar, com base em tipo e / ou teor de excepção.

Edit: É possível desativar (= cortar) o mecanismo de relatório de erros embutido no Windows para que o "crash e queimar" obrigatória de diálogo não são exibidas quando o seu aplicativo vai para baixo. No entanto, este torna-se eficaz para todas as aplicações no sistema, e não apenas o seu próprio.

Respondeu 04/08/2008 em 11:20
fonte usuário

votos
3

É este um aplicativo de console ou um aplicativo Windows Forms? Se é um aplicativo de console .NET 1.1 este é, infelizmente, pelo projeto - é confirmada por um dev MSFT no segundo post você referenciou :

BTW, na minha máquina 1.1 o exemplo do MSDN tem o resultado esperado; é só que a segunda linha não aparecer até depois que você anexa um depurador (ou não). Em v2 temos virou as coisas ao redor para que o evento é acionado UnhandledException antes dos adidos depurador, o que parece ser o que a maioria das pessoas espera.

Parece que o .NET 2.0 faz isso melhor (graças a Deus), mas honestamente, eu nunca tive tempo para voltar e verificar.

Respondeu 04/08/2008 em 03:45
fonte usuário

votos
1

É uma aplicação Windows Forms. As exceções que são capturados por Application.ThreadException funcionar bem, e eu não obter a caixa exceção .NET feio ( OKpara finalizar, Cancelpara depurar? Que surgiu com isso ??).

Eu estava ficando algumas exceções que não estavam sendo capturados por isso e acabou indo para o evento AppDomain.UnhandledException que estavam causando problemas. Eu acho que eu peguei a maioria dessas exceções, e eu estou mostrando-los à nossa caixa de erro agradável agora.

Então eu vou ter que espero não há algumas outras circunstâncias que poderiam causar exceções para não ser pego pelo manipulador Application.ThreadException.

Respondeu 04/08/2008 em 03:54
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more