3

我怀疑所有重要的软件都可能遇到遇到无法解决的外部问题并因此需要失败的情况。这可能是由于配置错误、外部服务器关闭、磁盘已满等原因。

在这些情况下，特别是如果软件在非交互模式下运行，我希望真正能做的就是记录错误并等待管理员阅读日志并修复问题。如果有人碰巧在此期间与软件交互，例如请求进入未能正确初始化的服务器，那么也许可以给出适当的提示来检查日志，甚至可以回显错误（取决于是否您可以判断他们是技术人员还是业务用户）。不过，我们暂时不要想太多这部分。

我的问题是，软件应该在多大程度上负责试图解释致命错误的含义？一般来说，您可以假定软件管理员有多少能力/知识，以及在记录致命错误时您应该包含多少故障排除信息和潜在的解决步骤？当然，如果运行时上下文有一些独特的东西，那么肯定应该记录下来；但是让我们假设您的软件需要通过 LDAP 与 Active Directory 通信并返回错误“ [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece]”。假设维护人员能够通过谷歌搜索错误代码并弄清楚它的含义是否合理，或者软件是否应该尝试解析错误代码并记录这是由 LDAP 配置中不正确的用户 DN 引起的？

我不知道是否有一个明确的最佳实践答案，所以我很想听听各种观点。

4

8 回答 8

3

对于所有广泛的问题，答案是“视情况而定”。

如果您正在查看配置错误，那么无论如何您都应该尝试解释错误的原因（在日志中）。如果这是一个内存不足的错误，那么您无能为力——您甚至可能无法编写日志消息。

你说的一件事与我有关：

如果在此期间有人碰巧与软件交互，例如请求进入未能正确初始化的服务器，那么也许可以给出适当的提示来检查日志

如果这确实是一个致命错误，则服务器不应该运行，因此任何传入的请求都应该失败，并且绝对没有警告或解释。

于 2009-02-19T12:34:09.483 回答
3

我倾向于同意的方法是，如果致命错误是由您自己负责的某些代码（即不是第三方）引起的，您应该尽可能多地解释。否则，如果错误是由“进一步向下”引起的，例如在数据库级别，那么管理员应该向上传递返回的错误，而无需添加更多进一步的信息。因此，如果数据库服务器死了，那么您的连接器会抛出一些异常，并且您将在异常中记录错误代码。

然后，管理员或支持人员应该有足够的知识来使用所提供的信息解决问题。

当您确实提供了太多不是由您自己的代码引起的错误的详细信息时，您将面临错误详细信息与实际错误原因不匹配的风险，特别是如果错误代码在版本之间停止匹配时。

当然，也有例外。我们曾与文档记录如此糟糕的开源库合作，以至于我们最终围绕这些库编写了包装器，只是为了提供对实际情况的良好记录。

只是我的2c

于 2009-02-19T12:46:27.380 回答
2

您至少应该提供来自异常的消息和堆栈跟踪，以便您可以找出它在代码中发生的位置。如果可能，您还应该根据异常类型解释您尝试执行的操作以及您认为可能发生的情况。

于 2009-02-19T12:35:20.510 回答
1

我想这取决于您在将软件交付给客户之前有多少时间。

是的，解析错误并给出更明确的消息会很好，但是在这个时代，谷歌并不总是很远。

因此，除非您有时间创建代码来解析错误，否则我会保持原样。

于 2009-02-19T12:34:24.570 回答
0

恕我直言，在这种情况下，您永远不能提供太多信息。

然而，在现实世界中，它归结为成本效益分析。错误对您、您的应用程序、您的业务等有什么影响。值得花多少时间在上面。

在业务关键型应用程序中，我的第一点适用。其他一切都是一个滑动规模。

于 2009-02-19T12:50:28.557 回答
0

我认为这取决于谁在使用该应用程序。

如果精通技术的人使用该应用程序，则显示更多技术细节，以便他们能够根据需要解决问题。我让一些用户不遗余力地解决问题。它非常有用，尤其是对于特定于某些配置的问题。

如果您的用户群更多的是普通的 Joe，那么在大多数情况下，技术细节会让他们感到困惑。您应该向他们展示一条简单的错误消息，并尽可能提供一些解决方案。

您也可以合并这两种技术。默认情况下显示简单的错误消息，并允许用户根据需要查看更详细的错误信息。

你只是不想用太多他们不理解的信息来压倒用户。在大多数情况下，这只会让他们感到沮丧和困惑。

于 2009-02-19T13:13:49.750 回答
0

我认为所有错误和异常都应该有两个方面：

1）错误中有足够的信息来帮助调试问题。Stacktrace、类/方法名、异常类型等都属于这一类。

2) 一条人类可以理解的消息，理想情况下足够清晰，让运维团队或系统管理员工程师知道该给谁打电话或转发该错误消息。通常它的形式是“某某模块失败”或“网络呼叫失败”等。用非技术术语向客户解释问题的方式很接近您。

现在由于时间限制等，可能无法同时编写两种消息。然后我会四处走动，说我们应该有第二种类型的错误消息。请记住，系统管理员可能会打电话给您，并且由于您帮助编写了代码，您可能可以查明错误。但是如果客户在电话中询问错误，系统管理员最好能够解释可能的原因:)

另一方面，所有产品都需要在架构级别确定明确的异常/错误处理机制。例外情况需要遵守该设计。没有什么比试图根据设计调试错误更令人沮丧的是，一天后才发现它是基于完全不同的设计的一种错误消息。

于 2009-02-19T18:19:35.803 回答
0

请参阅https://meta.stackexchange.com/questions/3122/formatting-sandbox

于 2010-04-26T13:02:14.010 回答