Question

在我的程序员的经验中，我尽可能地混合错误处理......我创造了我的个人风格。

但是，我想听一下你认为在方法的开头和结尾处的错误处理的赞成和利弊。

开头处理：

public String GenerateSomeStringData(String data, int value)
{
    if (data == null)
        throw new ArgumentNullException("data");

    if (value <= 0)
        throw new ArgumentException("value must be greater than zero");

    int dataValue;
    if (!int.TryParse(data, out dataValue))
        throw new InvalidOperationException("data does not contain an integer");

    return dataValue * 4 + value / 12;
}

最后处理：（同一个例子）

public String GenerateSomeStringData(String data, int value)
{
    if (data != null)
    {
        if (value > 0) 
        {
            int dataValue;
            if (int.TryParse(data, out dataValue))
            {
                return dataValue * 4 + value / 12;
            }
            else 
                throw new InvalidOperationException("data does not contain an integer");
        }
        else 
            throw new ArgumentException("value must be greater than zero");
    }
    else 
        throw new ArgumentNullException("data");
}

在决定如何处理此问题时，您使用什么标准？可读性，可维护性，简洁性？

Answer 1

输入的有效性应为precondition以执行方法 - 因此我会（并且确实）始终执行错误处理第一次。

这具有以下优点：

解析人类更容易：首先验证先决条件，然后执行逻辑（通常导致一些后期条件）
明确分离关注点错误处理和执行逻辑
在您的方法中：验证逻辑不会“嵌入”执行逻辑

如评论中所述，您必须区分违反前提条件的无效输入并触发错误条件（例如抛出异常）和构成边缘条件的有效输入（即需要一些要处理的特殊逻辑）。后面的例子我会在你的方法的执行逻辑开始时断言前提条件后单独处理。

Answer 2

正如其他人所提到的，我会在执行该方法的任何核心逻辑之前检查输入有效性。这不仅具有逻辑意义，而且还降低了代码缩进的级别，并且保证您没有任何if {}语句，这些语句太长，您无法在一个屏幕上看到else

Answer 3

第一种方法要好得多。

它可以帮助您将所有验证保存在一个位置。您甚至可以编写一个通用函数来处理这种类型的验证。

绝对更具可读性。您在开始时已完成所有验证，因此您可以了解您的实际逻辑。

如果您的代码跨越多一点，那么很难找到if循环的右括号。

Answer 4

我的意见是：首先检查错误状态，以便为其他人明确定义您的方法可行的内容以及哪些不正常。

在方法的开头到结尾处错误处理的优缺点是什么

4 个答案: