O Visual Studio 2015 interrompe as exceções não tratadas que não funcionam


114

O Visual Studio costumava ter uma caixa de seleção específica para "Interromper em exceção não tratada". Em 2015, ele foi removido (ou movido para algum lugar que não consigo encontrar). Portanto, agora meus projetos convertidos não quebram mais se eu deixar de fornecer um manipulador de exceção no nível do usuário. Não quero interromper todas as "exceções lançadas" porque lido com algumas específicas. Exatamente onde não consigo fornecer um manipulador específico.

No momento, meu código simplesmente sai do procedimento atual e continua a execução no próximo local da pilha de chamadas, NÃO É BOM.

Alguém sabe como recuperar isso no Visual Studio 2015? Acabei de atualizar para a edição da comunidade ontem.

Respostas:


118

Há uma nova janela chamada "Configurações de exceção" que aparece no painel inferior direito por padrão quando você começa a depurar. Ele tem todas as opções que você esperaria.

Você pode ativá-lo com CTRL+ ALT+E

Isso permite que você selecione quais exceções causam uma interrupção no depurador.

A chave, porém, é que você também pode definir se essas exceções sempre quebram ou apenas quebram quando é uma exceção não tratada - mas definir isso não é muito intuitivo.

Você precisará primeiro marcar "Habilitar Just My Code" em Ferramentas> Opções> Depuração.

Isso permite que você clique com o botão direito do mouse no cabeçalho da coluna (Break When Thrown) na nova janela Configurações de exceção e adicione a coluna "Ações adicionais", que permite definir cada exceção como "Continuar quando não tratada no código do usuário".

Portanto, basta clicar com o botão direito do mouse em uma exceção ou em um grupo inteiro e desabilitar o sinalizador "Continuar quando não tratado no código do usuário". Infelizmente, a coluna "Ações adicionais" aparecerá vazia, o que é o mesmo que "Interromper quando não manipulado no código do usuário".

insira a descrição da imagem aqui

Mais sobre isso aqui:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx


36

Eu tive o mesmo problema e consegui resolver isso fazendo isso -

  1. Pressione Ctrl+ Alt+ epara abrir as configurações de exceção janela .
  2. Marque Exceções de tempo de execução de linguagem comum . insira a descrição da imagem aqui

É isso aí!

Este post me inspirou porque estou usando uma versão x64 do Windows .


10

Para o googler que deseja interromper apenas quando a exceção diz respeito ao código, há uma opção no Visual Studio 2015: Opções-> Depuração-> Geral-> Apenas meu código. Uma vez marcada, ela permite não interromper quando a exceção é gerenciada (lançada e capturada) fora do seu código.


9

A Microsoft mudou sutilmente a lógica na nova janela de exceções.

Consulte http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

A parte principal é:

Anotações importantes

  • Esta nova janela contém todas as mesmas funcionalidades do antigo diálogo modal. Nenhum recurso do depurador mudou apenas a maneira como você pode acessá-los
  • O depurador sempre será interrompido quando uma exceção não for tratada
  • A configuração para mudar se o depurador quebrar em exceções não tratadas pelo usuário foi movida para um menu de contexto
  • A localização do menu mudou para Depurar -> Windows -> Configurações de exceção

No entanto , se como eu, você tem um Manipulador de exceções não tratadas global em seu código, o segundo item dessa lista é a chave: para mim, nenhuma exceção será, portanto, verdadeiramente não tratada, o que parece ser diferente do VS2013.

Para voltar ao comportamento em que o VS quebra em exceções não tratadas, eu tive que marcar todos os tipos de exceção que eu queria interromper e, em segundo lugar, garantir que as "Opções adicionais" (você pode precisar tornar esta coluna visível *) para "Continuar quando não tratado no código do usuário " NÃO foi definido. A lógica VS2015 não parece considerar meu Global Unhandled Exception Handler como "manipulado no código do usuário", portanto, ele não funciona; ele não quebra nas exceções detectadas. Isso faz com que funcione como o VS2013.

* Como habilitar a coluna "Ações adicionais" * Como habilitar a coluna "Ações adicionais"


7

Se estou lendo corretamente nas entrelinhas aqui, o problema é que sua exceção está efetivamente 'desaparecendo', embora o comportamento do depurador padrão seja interrompido em exceções não tratadas.

Se você tiver métodos assíncronos, pode estar enfrentando esse problema porque as exceções não detectadas em um thread do pool de threads como parte de uma continuação de tarefa não são consideradas exceções não tratadas. Em vez disso, eles são engolidos e armazenados com a Tarefa.

Por exemplo, dê uma olhada neste código:

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

Se você executar este programa com as configurações padrão do depurador (parar apenas nas exceções não tratadas), o depurador não será interrompido. Isso ocorre porque o thread do pool de threads alocado para a continuação engole a exceção (passando-a para a instância Task) e se libera de volta para o pool.

Observe que, neste caso, o verdadeiro problema é que o Taskretornado por Test()nunca é verificado. Se você tiver tipos semelhantes de lógica 'disparar e esquecer' em seu código, não verá as exceções no momento em que forem lançadas (mesmo que sejam 'não manipuladas' dentro do método); a exceção só aparece quando você observa a Tarefa esperando por ela, verificando seu Resultado ou olhando explicitamente sua Exceção.

É apenas um palpite, mas acho que provavelmente você está observando algo assim.


3

Na minha experiência, as configurações de exceção em 2015 ficam completamente fora de controle se você mudar alguma coisa.

Espere que se você até o grupo pai "CLR", então você não deve obter nenhum comando de quebra por não manipulado. Você sempre quebrará se uma exceção não for tratada. Mas, se você tiver o grupo CLR desmarcado, o código dentro de um try ... catch simplesmente não deve causar uma interrupção. Esse não é o caso.

Solução: Na nova caixa de ferramentas de configurações de exceção, clique com o botão direito e escolha "restaurar padrão". Taadaaaa ... Ele se comporta normalmente novamente. Agora não mexa com isso.


1

Tente seguir as instruções:

  1. Na janela Configurações de exceção, abra o menu de contexto clicando com o botão direito do mouse na janela e selecionando Mostrar colunas. (Se você desativou Just My Code, não verá este comando.)
  2. Você deve ver uma segunda coluna chamada Ações adicionais. Esta coluna exibe Continuar quando não tratada pelo código do usuário em exceções específicas, o que significa que o depurador não é interrompido se essa exceção não for tratada no código do usuário, mas for tratada no código externo.
  3. Você pode alterar essa configuração para uma exceção específica (selecione a exceção, clique com o botão direito e selecione / desmarque Continuar quando não tratado no código do usuário) ou para uma categoria inteira de exceções (por exemplo, todas as exceções do Common Language Runtime).

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx


1

É tudo um pouco confuso e, na minha opinião, não tão bom quanto o antigo diálogo de exceções, mas enfim.

Se uma exceção estiver na lista e marcada, o depurador será interrompido sempre que a exceção for lançada.

Se uma exceção estiver desmarcada ou não na lista, o depurador só será interrompido quando o tipo de exceção não for tratado pelo usuário.

Por exemplo, na captura de tela abaixo, o depurador será interrompido sempre que um System.AccessViolationExceptionfor lançado, mas para todas as outras exceções, ele apenas será interrompido se a exceção não tiver sido tratada pelo usuário.

Janela da ferramenta de exceções do Visual Studio 2015


1

Quando atualizei para o VS2015, também tive problemas em que as exceções costumavam "interromper" o aplicativo, mas agora são ignoradas e deixadas de lado. Há momentos em que queremos que nosso código lance intencionalmente exceções em lugares onde queremos que o código pare, em vez de continuar. Sempre usamos a frase Throw New Exception("Message")para fazer nosso código quebrar intencionalmente:

    If SomethingReallyBad = True Then
        Throw New Exception("Something Really Bad happened and we cannot continue.")
    End If

Com o VS2015, o clássico "System.Exception" é o que é lançado quando dizemos Throw New Exception. Portanto, precisávamos verificar a marcação "System.Exception" nas novas Configurações de exceção:

Verifique a caixa System.Exception

Uma vez verificado, nosso código funcionou conforme o esperado.


1

A solução para isso é semanticamente o oposto do que você pensa que está definindo. Você precisa se certificar de que Continuar quando não manipulado no código do usuário não está habilitado, ou seja, não verificado conforme mostrado na coluna Ações adicionais na guia Configurações de exceção - veja abaixo:

você está efetivamente dizendo para não continuar (ou seja, interromper) quando não manipulado no código

Janela Configurações de exceção (Control + Alt + E)

Para fazer isso:

  1. Clique com o botão direito na exceção ou no conjunto de exceções de seu interesse (ou seja, geralmente a linha superior 'Exceções de tempo de execução de linguagem comum' na árvore)
  2. Selecione a opção Continue When Unhandled in User Code (veja abaixo)
  3. Certifique-se de que as exceções não sejam verificadas (veja abaixo)
  4. continue depurando

insira a descrição da imagem aqui

Isso fez tudo para mim - feliz novamente.

Isso foi no VS 2015


0

Definitivamente, há algum bug no Visual Studio que pode travar e exigir uma reinicialização. Mesmo VS2015.

Tive uma única situação de thread em que a NullReferenceExceptionestava sendo capturado por um manipulador 'externo' (ainda em meu código), embora eu pedisse que ele quebrasse quando fosse gerado.

Sei que esta é uma exceção 'tratada' e você está falando de uma exceção 'não tratada' - no entanto, tenho certeza de que às vezes uma reinicialização rápida do VS corrigirá isso, se IISRESET não.


0

O Visual Studio 2017 funciona bem com tratamento de erros. O Visual Studio 2015, por outro lado, é péssimo no tratamento de erros com tarefas porque no modo de depuração todas as exceções que ocorrem em uma tarefa assíncrona são capturadas, mas, se eu passar por cima dela, apenas trava indefinidamente. Se executado sem depuração, ele trava indefinidamente sem exceção detectada !!! Eu amo estúdio visual e tenho usado desde 1995 e 2015 é a pior versão de longe, embora eu tenha pulado de 2010 diretamente para 2015. Passei 8 horas tentando fazer esse tratamento de exceções funcionar sem sucesso. Copiei o código exato para 2017 no meu computador doméstico e funcionou perfeitamente. Estou muito irritado porque a Microsoft empurrou as tarefas para uma estrutura que o compilador de 2015 não consegue lidar corretamente.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.