在什么特定情况下，将生成系统上的用户界面的StackTrace呈现给最终用户是好的（甚至是推荐的） 。
有大量的网站和SO文章，人们会问他们是否应该向最终用户展示StackTraces。毫不奇怪，答案是响亮的“不！”。
例如：
然而，我最近与另一位开发人员进行了对话，在那里我花了很多时间假设为什么堆栈跟踪不应该通过UI传递给用户。那次讨论让我回过头来重新审视我的一个基本（绝对）租户 - 用户永远不会看到生产中的原始StackTrace 。
我找不到一个引人注目的原因。但是，我确信有一个有效的用例，我想要理解它，或者继续坚持我的 绝对 租户。
答案 0 :(得分：7)
你没有 - 他们根本没有帮助用户。
用户获取消息。开发人员可以在日志，电子邮件，队列中获取堆栈跟踪，也可以在本地/内部运行时呈现HTML，等等。
答案 1 :(得分：2)
在这里，在我的办公室里有很多不同的内部项目，我从看到我的同事在我的程序崩溃时看到的堆栈跟踪中受益。他们只是没有恶意或知识足以知道发生了什么，否则他们会和我一起工作。它还给了我一个窗口期来询问用户可能确定他们正在做什么（虽然它在他们的脑海中仍然是新鲜的）。如果堆栈跟踪已被抑制或其他一些漂亮（但隐藏）错误处理已经到位，那么我可能不知道错误是如何发生的，而不是通过堆栈跟踪。
答案 2 :(得分：2)
当应用程序崩溃时，堆栈跟踪应该对用户可用，因为堆栈跟踪通常会识别导致崩溃的错误，并且可能存在可用的解决方法。这种解决方法显然只有在崩溃是由解决方法所造成的错误引起时才会起作用 - 否则尝试解决方法只是浪费时间。
崩溃也可能是由用户需要更新的内容中的错误引起的，例如：显卡驱动。在这种情况下，堆栈跟踪通常包含图形驱动程序的名称，例如atiumdag.dll。
让我们想象一下：
没有堆栈跟踪：
客户：我收到一个消息框，说“程序停止工作”。
支持：试试这个。
客户：不，没有帮助。
支持：试试这个。
客户：不，没有帮助。
支持：试试这个。
客户：不，没有帮助。
支持：试试这个。
客户：不，没有帮助。
使用堆栈跟踪：
客户：我收到一个消息框，说“程序停止工作”。
支持：点击“详细信息”按钮并将堆栈跟踪发送给我。
客户:(发送堆栈跟踪）
支持：这是由应用程序中的已知错误引起的，当应用程序安装在非默认路径中时，该错误由功能X触发。它将在下一个版本中修复，该版本将于明年发布。但是，您可以通过禁用功能X或在默认安装路径中重新安装应用程序来解决此问题。
答案 3 :(得分：1)
在开源项目中或打开调试模式的位置。也许用户正在使用该应用程序来了解该技术如何用于制作类似的应用程序，或者他们可能计划自己做出贡献。
有许多不同类型的用户。我认为允许他们打开这个选项很整洁，但是你的平均乔可能会偶然打开堆栈跟踪，这不应该那么容易。