我开发了一个自动崩溃报告系统，可以实时（通过电子邮件）发送最终用户应用程序发生的任何问题，我会得到所有详细信息（例如，哪个用户、哪个类/方法等）
这很棒，甚至崩溃报告系统本身也有一个辅助崩溃报告系统（以防它失败），它会写入日志文件。
从好的方面来说，我比客户/用户更快地收到错误警报；在某些情况下，我甚至在他们调用之前就解决了错误。
我的问题是何时将这些信息传回给客户以及传回多少。一方面它暴露了错误很棒，但同时这只是问题所在！我们是在踢自己的脚吗？
如果我们告诉他们，我们可能会得到否定的回应，如果我们不告诉他们，我们可能会得到否定的回应！
请指教！
我认为你应该告诉他们。传达坏消息（例如，“bug 将在 3 个月后的下一个版本中修复”）总比没有传达要好。
在客户注意到之前修复错误是一件非常好的事情。即使你不能那么快地修复一个错误，回答你的客户你已经意识到它并努力解决它也是好的。
请记住，最重要的是让软件“每次发布都少一些”。
无私的做法是告诉他们一切。但老实说，就让你的工作更轻松和让人们开心而言，这并不总是最好的做法。
在我从事 IT 工作时，一般来说，最好的规则是在他们要求时提供信息，但不要自愿提供，除非它会在不久的将来对他们产生负面影响（即停机时间）。这样你就不会让任何不在乎的人感到不安，而那些已经对你感到不安的人可以将这些信息作为和平祭品提供。
一般的经验法则是基本上保持低调，不要去戳不需要戳的东西/用户。
如果您的应用程序具有“状态消息”类型功能...只需在解决主要问题时更新...或者您想通知他们存在主要问题...
例如
“正在重新启动计费系统 - 预计停机时间：15 分钟”
“计费系统已备份 - 2009 年 7 月 17 日 13:54”
最终用户通常不会关心为什么某些东西不工作，只是“IT”知道它，并且有一个估计的时间来修复它。
所以“客户端模块中的空指针异常已修复”是毫无意义的......但是像这样的注释：
“上午 9:30 客户搜索屏幕的问题已得到修复。-上午 9:47”
我希望您通知他们应用程序以这种方式发送外部电子邮件，因为不通知现有的通信机制充其量是可疑的。
在通知客户方面，您可以采用统计方法，因为它们可以用于支持任何情况，例如在支持电话之前修复了多少错误等。但最终，开放式沟通的积极主动方法可能是一种比尽可能少地告诉他们等更好的政策。
然后进入与编程无关的问题，关于客户关系，建立信任和尊重的关系，期望管理等。
我的公司处理它的方式是，我们在存储过程、验证和此类......错误代码中的所有引发错误。这些通过 PK 映射到我们数据库中的表。然后我们有两个文本字段，用户友好版本和技术方面。
您可以做类似的事情，或者让您的异常处理包装更友好的消息，将其记录到数据库中，并在用户需要参考时为他们提供参考代码。
最后，我认为你现在做得比没有任何事情发生要好。
诚实地对待你的错误，诚实地对待它们的修复方式和时间。
对你的错误诚实将激励你通过改进你的质量保证流程来保持你的产品稳定。这应该会产生更稳定的产品，并且客户认为您的产品更稳定。
诚实地说明如何以及何时修复错误将改善您在客户服务和响应能力方面的形象。
通常的解决方案是让用户决定。与其自动发送邮件，不如问：“对不起，我刚刚崩溃了。我已经收集了有关问题的所有信息，现在可以将其发送给开发人员，以便解决问题。发送？是/否”
还要突出显示正在发送的数据，以便用户可以有根据地猜测他应该做什么。
[编辑] 您应该知道，当大多数用户发现您的应用程序在没有告诉他们的情况下调用 home 时，他们会非常不高兴，尤其是当它发送大量用户可能不想看到的数据时。
如果您的错误消息包含私人数据，您可能会因计算机欺诈而被起诉。