Práticas recomendadas para criar padrões de códigos de erro para um projeto corporativo em C # [closed]

38

Estou trabalhando em um projeto corporativo que será implantado em muitas SMBs e empresas.
O suporte para este projeto seria difícil e, por isso, quero criar um padrão de codificação para erros ( Like HTTP status Codes ). Isso permitirá que as pessoas do help desk se refiram aos documentos e solucionem os problemas o mais rápido possível.

Quais são as melhores práticas e recomendações para fazer isso?
Qualquer ajuda para fazer isso será útil.

    
por Pooya 28.08.2013 / 08:58
fonte

3 respostas

58

Existe uma diferença entre os códigos de erro e os valores de retorno de erro. Um código de erro é para o usuário e o suporte técnico. Um valor de retorno de erro é uma técnica de codificação para indicar que seu código encontrou um erro.

É possível implementar códigos de erro usando valores de retorno de erro, mas eu aconselharia isso. As exceções são a maneira moderna de relatar erros, e não há motivo para não conter um código de erro.

É assim que eu organizo (Observe que os pontos 2-6 são agnósticos em termos de linguagem):

  1. Use um tipo de exceção personalizada com uma propriedade ErrorCode adicional. A captura no loop principal relatará esse campo da maneira usual (arquivo de log / erro pop-up / erro de resposta). Use o mesmo tipo de exceção em todo o seu código.
  2. Não comece em 1 e não use zeros à esquerda. Mantenha todos os códigos de erro com o mesmo tamanho, para que seja fácil identificar um código de erro incorreto. A partir de 1000 geralmente é bom o suficiente. Talvez inclua um 'E' líder para torná-lo claramente identificável para os usuários (especialmente útil quando o suporte técnico tem que instruir os usuários sobre como identificar o código de erro).
  3. Mantenha uma lista de todos os códigos de erro, mas não faça isso no seu código . Mantenha uma pequena lista em uma página wiki para desenvolvedores, que eles podem editar facilmente quando precisarem de um novo código. O suporte técnico deve ter uma lista separada em seu próprio wiki.
  4. Não tente impor uma estrutura nos códigos de erro. Sempre haverá erros difíceis de classificar e você não deseja discutir por horas se um erro deve estar no grupo 45xx ou no grupo 54xx. Seja pragmático .
  5. Atribua a cada lance em seu código um código separado. Mesmo que você pense que é a mesma causa, o suporte técnico pode precisar fazer coisas diferentes em casos diferentes. É mais fácil para eles terem "E1234: Ver E1235" em seu wiki, do que fazer o usuário confessar o que ele fez de errado.
  6. Divida os códigos de erro se o suporte técnico solicitar. Uma simples linha if (...) throw new FooException(1234, ".."); else throw new FooException(1235, ".."); em seu código pode economizar meia hora para o suporte técnico.

E nunca se esqueça de que o objetivo dos códigos de erro é facilitar a vida do suporte técnico .

    
por 28.08.2013 / 13:52
fonte
6

Primeiro, você precisa isolar as áreas onde os erros podem ocorrer e são visíveis ao usuário. Então você pode documentá-los. É tão simples assim.

Bem, simples na teoria ... na prática, erros podem ocorrer em todo lugar, e denunciá-los pode transformar um código legal em um monstro de registro, lançamento e manipulação de exceções e passar valores de retorno.

Eu recomendaria uma abordagem em duas etapas. A primeira é registrar, registrar lotes e lotes.

O segundo é determinar os componentes principais e suas interfaces e definir em quais casos de erros principais esses componentes podem se encontrar. Você pode então efetuar login de uma forma mais visível quando um desses erros (como você lida com o erro internamente é até você - exceções ou códigos de erro não fazem diferença aqui). Um usuário geralmente verá o erro e acessará os registros para obter informações mais detalhadas.

A mesma abordagem é usada para servidores da web e seu exemplo de código de erro http. Se o usuário vir um 404 e relatar o suporte, ele procurará nos registros os detalhes do que estava acontecendo, a página que foi visitada, quando e coletará qualquer outra informação possível de qualquer outro lugar que faça sentido , esteja no banco de dados, na rede ou no aplicativo.

    
por 28.08.2013 / 11:10
fonte
4

Eu optaria por exceções personalizadas com nomes descritivos e mensagens claras e as jogaria. É muito mais fácil usar a infraestrutura de exceção existente de um idioma do que criar suporte para passar códigos de erro e interpretá-los.

    
por 28.08.2013 / 09:17
fonte