Como detalhado deve ser mensagens de erro?

Question

Eu queria saber o que o consenso geral sobre mensagens de erro era. Como detalhado deveriam ser?

Eu tenho trabalhado em projetos onde havia uma mensagem de erro diferentes para introduzir um número que era muito grande, muito pequeno, tinha um decimal, era uma corda, etc. Isso foi bastante agradável para o usuário como eles sabiam exatamente onde as coisas deram errado, mas o erro código de manipulação começou a rivalizar com a lógica de negócio real em tamanho, e começou a desenvolver alguns dos seus próprios erros.

Por outro lado, eu tenho trabalhado em um projeto onde você deseja obter erros muito genéricos como

COMPILE FALHOU RAZÃO 3

Qual Escusado será dizer que foi quase inteiramente inútil como razão 3 acabou por significar um erro de link.

Então, onde está o meio termo? Como eu sei se eu adicionei mensagens de erro bastante descritivas? Como eu sei se o usuário será capaz de entender onde eles têm errado for?

Answer 1

Existem duas possíveis públicos-alvo para uma mensagem de erro, o usuário, eo desenvolvedor.

Deve-se geralmente têm o destino da mensagem do usuário.

o que é a causa do problema.
o por que o programa não é possível contornar o problema
o que o usuário pode fazer para contornar o problema.
o como relatar o problema.

Se o problema deve ser relatado, o relatório deve incluir o máximo de informações de contexto programa possível.

o nome do módulo
o nome da função
o número da linha
o variáveis ??de interesse na área geral do problema
o talvez até um core dump.

atingir o público correto.

Answer 2

Você deve comunicar o que aconteceu, e quais as opções do usuário são, em tão poucas palavras quanto possível. Quanto mais tempo a mensagem de erro é, menos provável que o usuário é lê-la. Da mesma forma, as mensagens de erro curtas são enigmáticas e inútil. Há um ponto doce em termos de comprimento, e é diferente para cada situação.

Muito curto:

Entrada inválida.

Muito tempo:

Por favor, digite um endereço IP corretamente formatado, como 192.168.0.1. Um endereço IP é um número usado para identificar o computador em uma rede.

Apenas para a direita:

Por favor digite um endereço IP válido.

Quanto bloat código está em causa, se um pouco de código extra vai impedir que um usuário ligar para o suporte ou ficar frustraited, então é um bom investimento.

Answer 3

Existem dois tipos de mensagens de erro:. Aqueles que será visto pelo usuário e aquelas que vai ser visto pelo programador

"Como posso saber se o usuário será capaz de entender onde eles têm errado se foi?" Estou assumindo que essas mensagens são só vai ser visto pelo usuário, e não um muito técnico, e COMPILE FAILED REASON 3 não é uma típica mensagem de erro para o usuário final. algo que de que o programador vai ver (o usuário faz geralmente não coisas de compilação).

Então, se é o usuário que vai vê-lo:

1. Forneça uma breve "Esta é uma mensagem de erro" ( "Ops! Algo deu errado!", Etc.)
2. Fornecer uma pequena descrição genérica do erro ( "O site que você está tentando se conectar parece não estar disponível" / "Você não parece ter permissões suficientes para executar a tarefa XYZ" / etc.)
3. Adicionar um botão "Detalhes >>", no caso do seu utilizador passa a entender computadores bem, incluindo informações detalhadas (exceção rastreamento de pilha, código de erro, etc.)

Finalmente, fornecer algumas simples e comandos compreensíveis para o usuário ( "Tente outra vez", "Cancelar", etc.)

Answer 4

A verdadeira questão sobre mensagens de erro é se eles devem mesmo ser exibido. Um monte de mensagens de erro são apresentados a um usuário, mas não há nenhuma maneira para eles para corrigi-los.

Enquanto há uma maneira de corrigir o erro, em seguida, dar informações suficientes para o usuário que irá permitir-lhes para corrigi-lo por conta própria. Se eles não são capazes de corrigi-lo por conta própria há qualquer razão para dizer-lhes a razão técnica para o acidente? Não apenas registrá-lo em um arquivo para solução de problemas mais tarde.

Answer 5

Conforme detalhado como eles precisam ser;)

Eu sei que soa como uma resposta espertinho, mas muito disso depende de seu público-alvo eo tipo de erro. Para os erros causados ??pela entrada de usuário inválido, você pode mostrar-lhes o que constitui uma entrada válida. Para erros que o usuário não pode controlar, um genérico "nós estamos trabalhando nisso" tipo de mensagem pode fazer.

Eu concordo com os comentários de Jon B sobre comprimento também.

Answer 6

As mensagens de erro devem ser detalhadas, mas clara. Isto pode ser conseguido através da combinação de mensagens de erro a partir de vários níveis:

Failed to save the image
Permission denied: /foo.jpg

Aqui temos dois níveis. Não pode haver mais. Primeiro nós dizemos o retrato grande e então nós contar os detalhes. A ordem é tal que primeiro temos a parte compreendida pela maioria e, em seguida, a parte menos pessoas entendem, mas ambos ainda podem ser visíveis.

Além disso poderia haver uma sugestão de correção.

Answer 7

eu errar no lado de mais detalhes, mas eu acho que você respondeu sua própria pergunta. Para evitar o inchaço em código, em seguida, fornecer informações úteis na mensagem código / erro, mas você pode dar mais detalhes na documentação talvez ou com arquivos de ajuda ou FAQ.

tendo muito pouca informação é pior na minha opinião.

Se você estiver usando uma linguagem com a introspecção rico ou outras capacidades, um log witht ele linha que falhou uma verificação seria útil. O usuário pode, em seguida, para a frente para o suporte técnico ou de outra forma obter informações detalhadas e isso não é bloat código adicional, mas usando seu próprio código para fornecer informações.