Quando começar a escrever Tratamento de exceções, Log

Quando você começa a escrever seu código de manipulação de exceções? Quando você começa a escrever instruções de log.

Com o objetivo de elaborar essa pergunta, suponhamos que estamos na plataforma .NET com log4 log, mas fique à vontade para responder de maneira genérica.

Solução: Um Projeto Windows Forms. Projetos: UI, BusinessRules, DataHandlers

Então, você escreve seus DataHandlers, que fazem suas Manipulações de Dados, como Criar, Ler, Atualizar, Excluir primeiro.

Em seguida, siga-o com suas Regras de negócios

E então sua interface do usuário ou qualquer outra permutação acima.

Teste seu aplicativo para funcionalidade.

E então comece a escrever seu código de tratamento de exceções e, finalmente, o seu código de log?

Quando é o momento certo para começar a escrever seu código de Tratamento de exceções?

PS: No livro Código Limpo , eles dizem Escreva primeiro o bloco try-catch-finalmente . Isso me levou a fazer essa pergunta.

Você escreve seu código de manipulação de exceções ao escrever o que chama algo que pode causar exceções.

Por exemplo, ao escrever algo que envia dados para uma rede, você também deve escrever o código que lida com o tempo limite da conexão. A exceção é diretamente relevante para o que você está fazendo e o trabalho é renovado em sua mente.

Por outro lado, se você estiver gravando um analisador que gera exceções quando encontra uma unidade de dados de protocolo malformada, não pode escrever um código de tratamento de exceções para as exceções que o analisador produz . (Mas é claro que você está escrevendo testes para mostrar como, quando e por que o analisador gera exceções!)

A razão por trás da sugestão de escrever seu try-catch-finalmente primeiro é dupla: finalmente, é para limpar os recursos que a função cria / consome, e escrever o catch é um bom lembrete de que as funções que você está chamando podem falhar, e você precisa lidar com (se necessário) essas falhas.

Costumo adicionar log após o fato. Não tenho certeza se isso é sensato, mas é exatamente o que funcionou para mim. Quando começo a executar testes de aceitação e similares, e começo a encontrar problemas, adiciono o log para poder rastrear erros. (E então deixo o login.)

Na minha experiência, se você não escrever código com o tratamento e registro de erros apropriados desde o início, isso não será feito devido a pressões do tempo. Os esforços de desenvolvimento mais bem-sucedidos em que trabalhei começaram com o tempo gasto determinando a estrutura básica do aplicativo, incluindo o padrão de codificação, como os erros seriam tratados, o log, a arquitetura básica e as ferramentas de teste.

Caso contrário, você encontrará tarefas para a versão 2.0, como "Melhorar o tratamento de erros" e "criar sistema de log". Eles serão cortados em favor de novos recursos e, como você tem "muito a fazer", corrigindo todos esses erros nos casos de erro em que você não pensou. (O que leva uma eternidade, porque você não possui um sistema de log.

Depende do que você está fazendo

para exceções:

Se você estiver escrevendo algo que provavelmente apresentará erros ou algo em que haja bons pontos de nível superior para permitir que exceções surjam para escrevê-las à medida que avança.

Se você está escrevendo algo que precisa de desempenho e tem uma baixa possibilidade de erros e não possui um local significativo para colocar manipuladores de erros, escreva os manipuladores de erros onde os testes provam que você precisa deles.

Em qualquer um dos casos, se você não tiver nada útil com o erro, considere deixá-lo borbulhante (sem manipulador)

para registro:

Se você precisar de uma trilha de auditoria, primeiro escreva o log. Se você estiver deixando erros borbulharem até o topo, também precisará fornecer alguns registros para que o registro possa ser capturado.

Além desses casos, em geral, apenas adiciono o log nos locais onde o teste / uso prova que é necessário, e geralmente faço a opção de configurá-lo assim que terminar.

Você pode implementar auditoria e tratamento de exceções como serviços. O log de auditoria no nível do aplicativo requer dados de status sobre cada transação comercial. A capacidade de monitorar um aplicativo em um contexto comercial ou transacional requer uma interface de monitoramento dentro do serviço para enviar mensagens detalhando o status da transação específico para a chamada do serviço. Isso requer que cada serviço envie uma mensagem de status nas etapas críticas da transação comercial. Você pode criar um visualizador em tempo real para correlacionar as mensagens de status (com base na semântica da mensagem - por exemplo, ID da transação) com os serviços no aplicativo composto. Isso fornece uma visão de ponta a ponta da transação comercial para gerenciamento de SLA, rastreamento de falhas e determinação de problemas.

Um serviço de auditoria pode ser implementado como uma máquina de estado que pode consumir e registrar mensagens com base nos critérios definidos em sua configuração. Um manipulador de exceção genérico também pode usar o serviço de auditoria para oferecer suporte a uma visão centralizada dos problemas que ocorrem no SOA corporativo - para oferecer suporte ao monitoramento baseado em exceção. Qualquer condição de não ocorrer na solução é instrumentada para enviar uma mensagem de exceção para o manipulador de exceções.

Escreva quando precisar, mas projete para inclusão desde o início.

Em outras palavras: faça com que haja uma maneira de lidar com esse recurso de registro e adicione a funcionalidade real de parafusos e porcas (que mensagens ele registra) mais tarde, conforme a necessidade. Em exceções, adicione a captura (e, finalmente, se tiver) antes de escrever o arremesso. Isso ajudará a não esquecer um e salvar uma iteração ou, na pior das hipóteses, um bug / falha.