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

what to show to the user. Should this also be hidden from the user?

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

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

Or should we show this anyway? Or should we show a generic message?

Mostrando a exceção, pois o conteúdo da mensagem de erro principal é inútil para a maioria dos usuários . Talvez, se a sua base de usuários de destino for desenvolvedores, você possa mostrar as informações como erros completos 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.

should we show one of a number of messages based on what the underlying exception is?

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 nada diferente, diga algo como "ocorreu um erro inesperado".
• Adicione uma descrição de erro detalhada "opcional"
• Permitir que os usuários enviem o relatório de erros (ou faça isso automaticamente, dependendo da base de usuários)

Exemplo

1. Mostrao"aqui está o que aconteceu" (erro inesperado)
2. Informa ao usuário o que fazer (reabrir o Mail, até inclui um atalho para fazer isso)
3. Também tem um "ver detalhes" se alguém tiver interesse em ver o erro técnico completo
4. Fornece notificação de que um relatório de erro é arquivado (veja abaixo)

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

Depende de quem é o usuário e o que ele pode fazer com a informação.

Geralmente, tente mostrar apenas informações úteis sobre as coisas que eles podem resolver. Um rastreamento de pilha de 40 linhas com um erro de expressão regular no topo não é muito útil. Muito melhor seria uma mensagem que diz 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 eles podem não querer usar seu aplicativo, por medo de causar erros mais crípticos e assustadores (e, sim, usuários não técnicos às vezes ficam assustados com o empilhamento traços). E isso pode ser ruim para os negócios.

Para aplicativos internos usados por outros desenvolvedores, estou um pouco mais relaxado sobre exibir um rastreamento de pilha, além de algo mais útil , porque sei que o usuário pode manipular 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 OK mostrar a eles um rastreamento de pilha está em uma situação de erro crítico em que você precisa para resolver o problema, e eles são solicitados para copiar e colar o rastreio de pilha e enviá-lo para você, embora uma maneira muito melhor de fazê-lo seja pedir que ele envie um arquivo de log ou, melhor ainda, solicitar que o aplicativo envie um arquivo de log ao desenvolvedor. usuário para permissão para compartilhar o arquivo.

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

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

Este é um tema comum:

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

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 tem informações para pedidos avançados ou para usuários comuns ao relatar um problema

O que você quer mostrar depende de como você está envergonhado por ter errado.

O objetivo é obter os detalhes do fracasso do suporte técnico da maneira mais rápida e suave possível. Isso pode significar que você envie o arquivo de log incluindo o rastreamento de pilha do erro de finalização de volta para casa automaticamente ou peça ao usuário que clique em um botão que iniciará a transferência. Talvez através do stick USB, se não houver conexão com a internet.

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

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

Embora eu saiba pouco sobre aviação, meu voo está atrasado ou cancelado e a única coisa que a equipe me diz é: "Tivemos um erro inesperado. Aguarde 3 horas para um voo subseqüente". Você, pelo menos, me achará um cliente um pouco mais insatisfeito nesses casos, porque, embora isso não afete de fato o meu curso de ação, eu só quero saber um pouquinho mais sobre por que estou sendo incomodado dessa maneira como cliente pagante.

Se eles dissessem apenas: "Estamos passando por tempo turbulento" ou "Tivemos uma emergência médica em nosso voo anterior" ou um defeito no equipamento ou o que for, isso é suficiente para eu simpatizar muito mais do que "inesperado" erro "e ser um pouco mais contente sentado e esperando 3 horas para o próximo vôo. Na verdade, eu posso até preferir algum technobabble que passe por cima da minha cabeça para "erro inesperado" como: "Tudo bem, as palavras que saem da sua boca estão chegando ao meu ouvido, mas não atingindo o processador central. Mas agora tenho algum tipo de problema lá e eu vou pegar um pouco de café e sentar lá! Espero que vocês resolvam esse problema com essa coisa! "

E, muitas vezes, em termos de tratamento de exceções, acho que você geralmente tem informações básicas suficientes sobre o que aconteceu no site catch , 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 mesmo exibe o que pode potencialmente ser a informação muito técnica anexada à exceção, mas pelo menos nos diz muito mais do que "erro inesperado". Pelo menos fornece um contexto "what / where / when", mesmo que não diga "why / how". Eu acho que pelo menos o desejo por este nível básico de informação não é particularmente influenciado pelo meu conhecimento sobre computadores.

O restante é provavelmente muito específico para seus clientes e necessidades específicas. Mas o meu apelo é, pelo menos, para algo apenas um pouquinho mais do que "erro inesperado".