Uma das coisas mais difíceis que um desenvolvedor deve fazer é liberar o código do bug-riddled para o mundo, sabendo que eles nunca podem ouvir essas pequenas criaturas nunca mais.
O desenvolvedor experiente, então, deve ter algum tipo de mecanismo para que esses insetos possam chamar de lar e falar sobre suas aventuras em termos de usuário.
Talvez a configuração do relatório de erros seja exatamente isso:
Peço desculpas se você estivesse comendo enquanto lê isso.
Agora, pergunte ao seu engenheiro de rede amigável para uma planilha com todos os 404 que começam com /errors . Eles vão adorar isso.
Mas esse 'código' provavelmente não irá ajudá-lo a rastrear onde o erro ocorreu. Você quer ir um melhor e enviar uma mensagem contendo o arquivo e o número da linha:
Esse é o código legítimo limite, mas, como um esqueleto de grizzly atraente, ainda é um belo osso.
Se o erro estiver relacionado a alguns dados específicos, você não terá muita chance de replicá-lo.
Não seria bom se você tivesse um relatório completo da atividade do usuário para que você pudesse seguir suas etapas. Algo assim:
As partes interessantes são que o usuário navegou para uma página de detalhes do produto (etapa 4) e clicou no botão comprar (etapa 5, etapa final).
Diretamente, posso adivinhar que provavelmente há algo de duvidoso com os dados desse produto em particular, então eu posso ir ao URL e clicar no botão "Comprar isso por $".
Com certeza, quando faço isso, recebo o erro; Este produto em particular não teve preço, então, chamar para toLocaleString deu um erro. Erro de novato clássico.