Eu costumo construir um log de aplicativo, seja no banco de dados ou no arquivo, e registrar todas essas informações para isso. Você pode então fornecer ao usuário um número de erro, que identifica com qual item de log o erro está relacionado, para que você possa recuperá-lo. Esse padrão também é útil, já que você pode acompanhar os erros mesmo que os usuários não se incomodem em criá-los com você, para que você possa ter uma ideia melhor de onde estão os problemas.
Se o seu site estiver instalado no ambiente de um cliente e você não puder alcançá-lo, você poderá obter o departamento de TI no local para enviar um extrato com base no erro nº.
A outra coisa que você pode considerar é fazer com que o sistema envie por e-mail detalhes de erros para uma caixa de correio que você tenha visto, para saber quando as coisas estão dando errado.
Fundamentalmente, ter um sistema que solta sua coragem quando algo não está certo não inspira confiança em usuários não-técnicos - isso tende a assustá-los e faze-los pensar que algo está errado (por exemplo, quanto de BSOD você entende, e como você se sente quando surge?
No stacktrace:
No .Net, o rastreio de pilha mostrará o rastreio completo diretamente nos principais conjuntos MS-sourced e revelará detalhes sobre quais tecnologias você está usando e as possíveis versões também. Isso dá aos intrusos informações valiosas sobre possíveis pontos fracos que podem ser explorados.