在C＃中为企业项目创建错误代码模式的最佳实践

我正在研究一个将在许多SMB和企业中部署的企业项目。
对这个项目的支持会很艰难，因此我想为错误创建一个编码模式（例如HTTP status Codes）。这将使服务台人员能够查阅文档并尽快解决问题。

有哪些最佳实践和建议？
这样做的任何帮助将非常有用。

错误代码和错误返回值之间存在差异。错误代码适用于用户和服务台。错误返回值是一种编码技术，用于指示您的代码遇到错误。

可以使用错误返回值实现错误代码，但我建议不要这样做。异常是报告错误的现代方法，没有任何理由不应该在其中携带错误代码。

这就是我的组织方式（请注意，第2-6点与语言无关）：

1. 使用具有附加ErrorCode属性的自定义异常类型。主循环中的catch将以通常的方式报告此字段（日志文件/错误弹出窗口/错误回复）。在所有代码中使用相同的异常类型。
2. 不要从1开始，也不要使用前导零。保持所有错误代码的长度相同，因此很容易发现错误的错误代码。通常从1000开始就足够了。也许添加一个前导“ E”以使用户可以清楚地识别它们（在支持台必须指示用户如何发现错误代码时特别有用）。
3. 保留所有错误代码的列表，但不要在代码中执行此操作。在开发人员的Wiki页面上保留简短列表，供开发人员在需要新代码时轻松进行编辑。服务台应在自己的Wiki上有一个单独的列表。
4. 不要尝试对错误代码强制执行结构。总是会有难以分类的错误，您不想花数小时来讨论错误应该属于45xx组还是属于54xx组。务实。
5. 在代码中为每个抛出分配一个单独的代码。即使您认为是同一原因，帮助台在不同情况下也可能需要做不同的事情。对于他们来说，在他们的Wiki中拥有“ E1234：请参见E1235”要比让用户承认自己做错了要容易得多。
6. 如果服务台要求，请分割错误代码。if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");您的代码中简单的一行可能会为帮助台节省半小时。

而且永远不要忘记，错误代码的目的是使服务台的工作更轻松。

您首先必须隔离可能发生错误并且对用户可见的区域。然后，您可以记录它们。就这么简单。

好吧，从理论上讲是简单的。在实践中，错误可能会在该死的地方发生，并且报告错误可以将漂亮的代码变成记录，异常抛出和处理以及传递返回值的庞然大物。

我会建议采用两步法。首先是记录，记录很多。

其次是确定主要组件及其接口，并定义这些组件可以发现哪些主要错误情况。然后，当这些错误之一（内部如何处理错误取决于您）时，您可以以更直观的方式登录。 -异常或错误代码在这里没有区别）。然后，用户通常会看到该错误并转到日志以获取更多详细信息。

Web服务器和您的http错误代码示例使用相同的方法。如果用户看到404并将其报告为支持，则他们将在日志中查找正在发生的事情，访问的页面，时间的详细信息，并将从任何其他有意义的地方收集其他信息，位于DB，网络或应用程序中。

我将使用具有描述性名称的自定义异常并清除消息并将其抛出。使用语言的现有异常基础结构要比建立对传递错误代码和解释错误代码的支持要容易得多。