Quanta informação sobre um erro deve ser mostrada ao usuário?

Os aplicativos sempre podem gerar erros. Se ocorrer esse erro, o usuário deve ser notificado, porque o que ele pediu para o aplicativo não ter êxito.

No entanto, quanta informação o usuário deve receber? Acho que a maioria de nós concorda em não mostrar um rastreamento de pilha ( um rastreamento de pilha deve estar na mensagem de erro apresentada ao usuário? ), Mas não consigo encontrar uma pergunta sobre o restante do conteúdo do erro ou o que mostrar ao do utilizador.

Por exemplo, um idioma que suporta exceções (.net, java) tem o tipo de exceção a ser compartilhado, onde ocorreu a exceção, e uma mensagem um pouco esclarecedora para acompanhar a exceção. Isso também deve estar oculto para o usuário? Ou devemos mostrar isso de qualquer maneira? Ou devemos mostrar uma mensagem genérica? ou devemos mostrar uma de várias mensagens com base em qual é a exceção subjacente?

o que mostrar ao usuário. Isso também deve estar oculto para o usuário?

Você mostra ao usuário o que é acionável para ele.

Por exemplo, se você tiver um erro causado por alguma exceção de ponteiro nulo e mais um bug que um erro de usuário, não deseja uma explicação completa, porque eles não podem fazer nada diferente.

Ou devemos mostrar isso de qualquer maneira? Ou devemos mostrar uma mensagem genérica?

Mostrar a exceção como o conteúdo principal da mensagem de erro não faz sentido para a maioria dos usuários . Talvez se sua base de usuários-alvo for desenvolvedores, você poderá mostrar as informações como erro completo o tempo todo (talvez você tenha um aplicativo interno para testes automatizados). Mas geralmente os usuários não podem fazer nada diferente, mesmo com esse conhecimento.

devemos mostrar uma de várias mensagens com base em qual é a exceção subjacente?

A melhor estratégia é fazer o seguinte:

• Interprete o erro em texto que seja significativo para o usuário.
  • Parte disso é "o que o usuário pode fazer de diferente?"
  • Se eles não puderem fazer algo diferente, diga algo como "ocorreu um erro inesperado".
• Adicione uma descrição detalhada "opcional" do erro
• Permitir que os usuários enviem o relatório de erros (ou faça isso automaticamente, dependendo da base de usuários)

Exemplo

1. Ele mostra o "aqui está o que aconteceu" (erro inesperado)
2. Informa ao usuário o que fazer (reabra o Mail, inclusive inclui um atalho para fazer isso)
3. Também possui "visualizar detalhes" se alguém estiver curioso para ver o erro técnico completo
4. Fornece notificação, um relatório de erro é arquivado (veja abaixo)

Observe que, em alguns casos, você pode desejar que o relatório de erros seja manual ou automático.

Depende de quem é o usuário e o que eles podem fazer com as informações.

Geralmente, tente mostrar a eles apenas informações úteis sobre as coisas que eles mesmos podem resolver. Um rastreamento de pilha de 40 linhas com um erro de expressão regular na parte superior não é muito útil. Muito melhor seria uma mensagem informando que Data deve ser formatada como "aaaa-mm-dd" . Qualquer outra coisa, e o usuário pode não saber como responder ao erro e, em seguida, pode não querer usar seu aplicativo, por medo de causar mais erros enigmáticos e assustadores (e sim, às vezes, usuários não técnicos ficam assustados com a pilha traços). E isso pode ser ruim para os negócios.

Para aplicativos internos usados ​​por outros desenvolvedores, estou um pouco mais relaxado em exibir um rastreamento de pilha, além de algo mais útil , porque sei que o usuário pode lidar com a visualização de um rastreamento de pilha e provavelmente saberá o que fazer sobre isso.

Para usuários não técnicos, a única vez em que acho que seria bom mostrar a eles um rastreamento de pilha está em uma situação de erro crítico em que você precisa resolver o problema e eles são solicitados a copiar e colar o rastreamento de pilha e enviá-lo para você, embora realmente seja uma maneira muito melhor de fazê-lo, peça que eles enviem um arquivo de log ou, melhor ainda, solicite ao aplicativo que envie um arquivo de log ao desenvolvedor, depois de pedir ao usuário permissão para compartilhar o arquivo.

As mensagens para os usuários devem ser tratadas da mesma maneira que a criação de uma nova exceção a ser lançada - você fornece as informações necessárias para decidir o que fazer.

Obviamente, isso dependerá do seu aplicativo e da base de usuários, mas deve ser o seu principal orientador - sua intenção deve fornecer as informações necessárias para o "responsável pela chamada" para determinar o que eles podem fazer para executar com êxito a ação desejada. . Se for algo simples como um erro de acesso a um arquivo, você fornece um caminho para o arquivo e a mensagem que não pôde acessá-lo. Se for uma exceção de ponteiro nulo, basta fornecer uma mensagem de erro genérica.

É claro que haverá mais mensagens "incapazes de executar a ação desejada" do que aquelas que o usuário pode consertar, mas isso é apenas vida - a maioria das exceções ocorre porque cometemos um erro, não porque o usuário configurou o ambiente incorretamente.

Este é um tema comum:

Como você pode ajudar analfabetos desinformados / computador, ao mesmo tempo em que mostra informações que usuários mais avançados, como programadores, desenvolvedores, testadores, etc. podem usar.

Eu acho que a resposta é você fazer as duas coisas!

A ordem é importante e eu recomendo que você tenha:

• O que aconteceu.
• O que fazer agora
• Detalhes técnicos

Detalhes técnicos é a parte que contém informações para pedidos avançados ou para usuários regulares ao relatar um problema

O que você quer mostrar depende de quão envergonhado você está por estragar tudo.

O objetivo é obter os detalhes da falha no suporte técnico o mais rápido e sem problemas possível. Isso pode significar que você envia o arquivo de log, incluindo o rastreamento de pilha do erro de encerramento automaticamente, para casa ou pede ao usuário para clicar em um botão que iniciará a transferência. Talvez através do pen drive, se não houver conexão com a internet.

Gosto da lógica por trás da resposta aceita, mas devo discordar respeitosamente, pelo menos com a minha interpretação de limitar as informações ao que é "acionável" . Eu quero saber um pouco mais do que isso como usuário do que "erro inesperado" .

E, reconhecidamente, sou um pouco experiente em computadores e tenho esse viés, mas não acho que essa seja uma visão particularmente tendenciosa. Porque posso fazer o possível para remover esse viés aplicando essa mentalidade a domínios para os quais tenho pouca experiência, como a aviação.

Embora eu saiba pouco sobre a aviação, diga que meu voo está atrasado ou cancelado e a única coisa que a equipe me disse é: "Tivemos um erro inesperado. Aguarde 3 horas para um voo subsequente". Você pelo menos vai me achar um cliente mais insatisfeito nesses casos porque, mesmo que isso não afete meu curso de ação, quero apenas saber um pouco mais sobre o motivo de estar sendo incomodado dessa maneira como cliente pagante.

Se eles apenas disserem: "Estamos enfrentando um clima turbulento" ou "Tivemos uma emergência médica em nosso voo anterior" ou um mau funcionamento do equipamento ou o que seja, basta o bastante para simpatizar muito mais do que "erros inesperados" e fique um pouco mais satisfeito esperando e aguardando 3 horas pelo próximo vôo. Na verdade, eu até prefiro algumas conversas tecnológicas que passam pela minha cabeça a "erros inesperados" como "Tudo bem, as palavras que saem da sua boca estão entrando no meu ouvido, mas não atingindo o processador central. Mas agora percebo que existe algum tipo da questão lá e eu vou pegar um café e sentar lá! Espero que vocês resolvam esse problema com essa coisaamajig! "

E, geralmente, em termos de tratamento de exceções, acho que você normalmente tem esse tipo de informação básica do que aconteceu no catchsite, mesmo que queira ocultar os detalhes mais técnicos da exceção, como:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

E isso nem está exibindo o que potencialmente pode ser a informação muito técnica anexada à exceção, mas pelo menos está nos dizendo consideravelmente mais do que "erro inesperado". Pelo menos, fornece um "quê / onde / quando" contextual, mesmo que não diga "por que / como". Acho que pelo menos o desejo por esse nível básico de informação não é particularmente influenciado pela minha inteligência em computadores.

O resto é provavelmente muito específico para seus clientes e necessidades particulares. Mas meu apelo é pelo menos para algo um pouquinho mais do que "erro inesperado".