Práticas recomendadas para criar padrão de códigos de erro para um projeto corporativo em C # [fechado]

Estou trabalhando em um projeto corporativo que será implantado em muitas PMEs e empresas.
O suporte para este projeto estaria com dificuldades e, por isso, quero criar um padrão de codificação para erros ( como códigos de status HTTP ). Isso permitirá que o pessoal do suporte técnico consulte os documentos e solucione 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.

c# programming-practices error-handling enterprise-development

— Pooya
fonte

Existem muitas respostas possíveis ou boas respostas seriam muito longas para este formato. Adicione detalhes para restringir o conjunto de respostas ou para isolar um problema que pode ser respondido em alguns parágrafos. E o que você tentou até agora.

— Ben McDougall

Depende de como sua empresa está estruturada. Em C #, sempre demos ao usuário a possibilidade de nos enviar o StackTrace ou copiá-lo / colá-lo a partir dos detalhes da mensagem de erro (não tínhamos requisitos rígidos de segurança).

— Falcon

Respostas:

Há uma diferença entre códigos de erro e 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.

Pode-se implementar códigos de erro usando valores de retorno de erro, mas eu aconselho isso. As exceções são a maneira moderna de relatar erros e não há razão para que eles não devam carregar um código de erro dentro delas.

É assim que eu organizaria (observe que os pontos 2 a 6 são independentes de idioma):

Use um tipo de exceção personalizado com uma ErrorCodepropriedade adicional . A captura no loop principal reportará esse campo da maneira usual (arquivo de log / pop-up de erro / resposta a erro). Use o mesmo tipo de exceção em todo o seu código.
Não comece com 1 e não use zeros à esquerda. Mantenha todos os códigos de erro do mesmo tamanho, para que seja fácil identificar um código de erro errado. A partir de 1000 geralmente é bom o suficiente. Talvez adicione um 'E' principal para torná-los claramente identificáveis para os usuários (especialmente útil quando o suporte técnico precisar instruir os usuários a identificar o código de erro).
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 precisam de um novo código. O suporte técnico deve ter uma lista separada em seu próprio wiki.
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 .
Atribua a cada lançamento em seu código um código separado. Mesmo que você ache que é a mesma causa, o suporte técnico pode precisar fazer coisas diferentes em casos diferentes. É mais fácil para eles ter "E1234: Veja E1235" em seu wiki, do que fazer com que o usuário confesse o que fez de errado.
Divida os códigos de erro se o suporte técnico solicitar. Uma if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");linha simples no seu código pode economizar meia hora para o suporte técnico.

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

— Sjoerd
fonte

Eu nunca fiz isso pessoalmente, mas muitas vezes você vê "IDs de correlação", também, guias específicos da instância de erro que são exibidos ao usuário e também registrados. Dessa forma, você pode encontrar com mais facilidade a ocorrência exata do erro nos logs, mais facilmente do que com um tempo aproximado e um código de erro.

— Xdhmoore 23/05

Suponho que provavelmente haja uma maneira de incluir o código de erro no ID de correlação, para que ele possa servir como um código de erro legível por humanos para o suporte técnico e como um ID de instância de erro para desenvolvedores.

— Xdhmoore 23/05

Meu padrão é bem parecido. Mas, em vez de "E", adicionei um pouco da parte do aplicativo. Nossa estrutura de documentação tem, por exemplo, um Doc1234tempo que o aplicativo principal pode ter IrS1234. Portanto, meus colegas de assistência técnica são muito rápidos em ajudar meus usuários.

— Matthias Burger

Você primeiro precisa isolar as áreas onde os erros podem ocorrer e ficar visível ao usuário. Então você pode documentá-los. É simples assim.

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

Eu recomendaria uma abordagem em duas etapas então. Primeiro é registrar, registrar lotes e lotes.

O segundo é determinar os principais componentes e suas interfaces, e definir em quais casos de erros principais esses componentes podem se encontrar. Você pode fazer o logon de maneira mais visível quando um desses erros (como você lida com o erro internamente é sua escolha). - exceções ou códigos de erro não fazem diferença aqui). Um usuário geralmente vê o erro e acessa os logs 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 vê um 404 e o informa como suporte, ele procurará nos logs os detalhes do que estava acontecendo, qual página foi visitada, quando e coletará qualquer outra informação possível de onde quer que seja. , esteja no banco de dados, na rede ou no aplicativo.

— gbjbaanb
fonte

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

— Stefan Billiet
fonte

Gostaria muito de receber a pessoa que downvoted esta resposta 1-0, pelo menos, dar uma razão ...

— Stefan Billiet

não fui eu que fiz voto negativo (não que isso importe, supere isso), mas acho que também existe suporte para valores de retorno no idioma.

— Gbjbaanb

Isso importa a mim; se estiver errado, gostaria de saber para aprender :-p Como assim, suporte existente para valores de retorno? Você não precisaria escrever canalizações para diferenciar um valor de retorno normal de um código de erro? Traduzir uma exceção para um código de erro nos limites de um sistema é uma coisa, mas manipulá-los dentro do sistema é algo que geralmente não é recomendado. Eu acredito que o Programador Pragmático menciona esse tipo de coisa.

— Stefan Billiet

as exceções não são um bom mecanismo em todos os casos, mas se você decidir usar erros, poderá adicionar um parâmetro de saída a cada chamada ou fazer com que chamadas importantes retornem um código. Apenas decida fazer isso com antecedência, e você é ouro. Pragmaticamente, você acaba misturando os dois códigos de erro retornados nos limites (para não ficar preso em um único idioma) e usando exceções internamente.

— Gbjbaanb 28/08

Eu não votei contra você (vá com calma, caso contrário todos terão que repetir isso :). Se você trabalhou ou ligou para o service desk, é muito mais fácil comunicar apenas um número curto do que uma mensagem de erro. É garantido que uma mensagem de erro seja alterada quando for comunicada oralmente.

— Codism 28/08