c# - 处理常见错误 : If-Then-Throw blocks vs. 代码契约与断言类

Question

当我开始编写方法时，我通常首先使用 If-Then-Throw block 检查方法中的异常情况。

public void ReadFile(string filePath)
{
    if (string.IsNullOrEmpty(filePath)
    {
        throw new ArgumentException(...

这种风格看起来非常清晰易懂，但它占用的空间比我认为必要的要多。我希望能够以一种聪明的方式处理错误和异常情况，使阅读这些错误的人能够轻松处理这些错误，同时保持代码本身干净。

我看过一些代码契约，在我看来，它似乎是方法执行前后某些条件的要求。对于一个空字符串来说，这似乎有点矫枉过正，而且我不确定你是否可以在方法本身中包含契约(Contract)条款，例如，如果路径不为空但该路径不存在文件。

我正在考虑使用的解决方案是滚动我自己的 Assert 类。这个类基本上会将上面的 If-Then-Throw 变成一个简单的 one liner。

Assert.IsFalse<ArgumentException>(string.IsNullOrEmpty(filePath), "The path cannot be null or empty.");

所有断言方法都会使用最后一个参数中的异常类型和消息抛出异常。问题是我不确定这是否是好的做法。它是否混淆了异常的真正含义，或者 Assert 的实际含义？它会使错误处理更容易还是更难？

Answer 1

我会说这不是好的做法。正如您所指出的，这会混淆断言和异常的角色。话题有点共同，this link有很多好的想法。通过结合异常和断言，您最终会遇到一个难题……该类是异常助手还是断言助手？

由于断言是从 Release 构建中编译出来的，您的断言类甚至可以在 Release 模式下工作吗？期望断言类在 Release模式下工作是非常规的。那么，您的 Assertion 类会在 Release 模式下抛出异常吗？这就是困惑所在。按照惯例，我会说在使用断言类(在 Release模式下)时不应抛出异常，因为据了解断言不是发布构建的一部分。

上面的代码不应该使“异常处理”变得更容易或更难，它应该是相同的，因为异常处理取决于堆栈中捕获异常的内容。我认为您真的是在问它是否使抛出异常变得更容易或更难。我认为这可以使处理您的异常更容易。我也认为这可能是不必要的。最重要的是您要与此保持一致……如果您打算使用 ExceptionHelper 类，那么接受它并保持一致……否则一切都是徒劳的。

调试断言:

• 自由使用
• 只要假设有可能是错误的就使用
• 用于帮助其他程序员，不一定是最终用户
• 不应该影响程序的流程
• 未在发布版本中编译
• 总是在发生意外时大喊“BLOODY MURDER”，这是好事
• 还有很多其他原因，我不打算列出完整的 list

异常(exception)情况:

• 可以由任何原因引起，原因不明
• 始终在调试或发布版本中
• 关于应用程序的流程
• 一些异常处理程序可能会默默地吞下一个异常，而您永远不会知道
• 还有很多其他原因，我不打算列出完整的 list