Por que devo escrever todas as instruções no Try-Catch?

O chefe da minha empresa diz que devo escrever tudo, ou seja, TODO meu código nas instruções Try-catch. Agora, eu posso entender a abordagem 'é melhor prevenir do que remediar' aqui, mas não é muito corajoso pensar que haverá uma exceção quando os Rótulos forem criados, a posição do formulário for definida. houve casos em que Exceções em tais operações simples.

O chefe da minha empresa diz que devo escrever tudo, ou seja, TODO meu código nas instruções Try-catch.

Bem, isso é um pouco exagerado e apenas leva a códigos barulhentos. Quais são os benefícios de ter todo o código (cada método, por exemplo) escrito com um manipulador try catch? Apenas informa que há um erro a ser corrigido na maioria dos casos. Muitas vezes, a exceção pode e deve ser evitada em primeiro lugar.

Uma olhada no rastreamento da pilha é suficiente para revelar a causa no seu código, mesmo que o método com falha não execute a captura propriamente dita. Há momentos em que os desenvolvedores corrompem rastreamentos de pilha em exceções, mas esse é muito mais frequentemente o caso quando você tem muitos e muitos manipuladores de exceção. Como qualquer coisa: um pouco é bom, mas muito é veneno.

O tratamento de exceções é realmente muito simples:

Exceções de captura

• sempre que você precisar de uma ação especial como reação à exceção
• sempre que uma exceção deixar o programa em um estado inconsistente se não for tratado

Se você pensar bem, sempre há apenas um lugar que é bom para lidar com uma exceção que ocorre. E assim o manipulador deve estar naquele lugar.

Muitas exceções nem deveriam ser lançadas em primeiro lugar; portanto, não construa suas estruturas de controle em torno do tratamento de exceções, tente evitar a possível ocorrência de exceções sempre e sempre que possível.

Lembre-se de travar cedo quando as coisas derem errado (irreparavelmente). Colocar todo o código nas instruções try-catch é um absurdo, mas não se esqueça de relatar e registrar TODAS as exceções.

mas não é muito corajoso pensar que haverá uma exceção quando os Rótulos forem criados, a posição do formulário estiver definida. houve casos em que Exceções em tais operações simples.

Absolutamente sim! Há sempre uma maneira de as coisas darem errado que você não previu. E "coração de galinha" é uma expressão ridícula para usar neste contexto; desenvolvimento de software não significa provar seu machismo ignorando possíveis problemas.

O que é uma pergunta válida é se é útil que as exceções sejam detectadas no ponto em que seus padrões de codificação dizem que precisam. Sua declaração diz que você precisa ter o bloco try / catch em todo corpo do método, e isso é realmente um absurdo, porque muitas vezes você não pode fazer algo imediatamente útil com uma exceção, e esse é realmente o ponto principal das exceções: você pode optar por deixá-los propagar a pilha de chamadas a ser tratada no ponto apropriado.

Eu mudaria isso ao contrário. Sim, como regra geral, o tratamento de exceções é uma coisa boa, mas você pode realmente lidar com todas as exceções possíveis de maneira sensata no ponto em que é capturado? Às vezes, principalmente se você não está escrevendo software de missão crítica, é melhor simplesmente travar e queimar de alguma maneira controlada pela metade quando as coisas dão terrivelmente errado.

Se você não pode estar 100% certo de que pode lidar com todas as exceções que possam ser capturadas, provavelmente é melhor escrever algum tipo de manipulador de exceção geral, envolvendo o loop principal do programa - a mecânica exata de como fazer isso obviamente depende o idioma que você está trabalhando em Não, ingresse o máximo de detalhes sobre a exceção como você pode, salvo estado do programa (em algum lugar. outro do que para qualquer dado armazenar o usuário está trabalhando contra - lembre-se, tudo pode ser corrompido, neste ponto ), e assim por diante. Em seguida, repita a exceção e deixe o SO lidar com ela da maneira que achar melhor. Neste manipulador de exceção abrangente, esteja preparado para falhas catastróficas. Então, quando o programa for reiniciado, verifique se esse estado é de alguma forma útil e restaure o que pode ser recuperado, se for; e possivelmente ofereça ao usuário o envio de um relatório de bug para você.

No geral, o uso de try / catch é obsoleto, porque o bloco de catch é muito caro do ponto de vista dos recursos. O uso try / catch me lembra o gerenciamento de riscos . O gerenciamento de riscos tem duas dimensões:

1. A probabilidade de risco acontecer
2. O dano que isso pode ter

Agora, se você sair de casa, um piano caindo sobre sua cabeça em algum lugar é muito improvável que isso aconteça (talvez 0,001%), mas pode matá-lo.

O tratamento de exceções é assim. Tente bloco não é caro. Mas o bloco catch é realmente caro, porque precisa criar uma tabela de rastreamento de pilha e fazer outras coisas. Portanto, ao tomar uma decisão sobre os blocos try / catch, considere quantas vezes você provavelmente bate no bloco catch. Se entre 10.000 usos, você o acertar apenas 1 vez, use-o. Mas, se for um formulário, e o usuário provavelmente não o preencher corretamente 50% vezes, evite colocar um bloco try / catch em ação lá.

Em locais onde a probabilidade de ocorrência de exceções é alta, é recomendável usar if {} else {}blocos para evitar a ocorrência de exceções. Por exemplo, onde você deseja dividir dois números, em vez de escrever:

try
{
    int result = a/b;
}
catch (DivisionByZeroException ex)
{
    // Showing a message here, and logging of course.
}

você deve escrever:

if (b == 0)
{
    int result = a/b;
}
else
{
    // Showing a message to user to change the value of b, etc.
}

Você deve usar o try-catch quando apropriado, mas, por favor, não pegue todas as exceções e nem registre-as. Nesse ponto, é o cheiro do código e o trabalho de má qualidade.

Pessoalmente, não suporto exceções, são MUITO, MUITO, MUITO difíceis de manipular corretamente. E tentar corromper os dados corrompidos é MUITO, MUITO, MUITO difícil!

http://blogs.msdn.com/b/mgrier/archive/2004/02/18/75324.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

http://www.joelonsoftware.com/items/2003/10/13.html

Se você não chamar todas as funções como:

try
{
    TrivialFunction();
}
catch(TypeAException)
{
    //MaybeFix
}
catch(TypeBException)
{
    //MaybeFix
}
catch(TypeCException)
{
    //NO FIX - CORRUPT DATA
}
catch(TypeDException)
{
    //NO FIX - UNKNOWN STATE
}
catch(OutOfMemoryException)
{
    //Try to fix this one! Destructors might allocate on their own ;)
}
catch(Exception)
{
    //Nothing to see here, move on, everything is OK ;)
}

Não há como limpar corretamente todos os pontos de saída. Exceções são DIFÍCIL!

A única coisa boa das exceções é que, se você não as capturar, o aplicativo trava devido a um comportamento inesperado.