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