返回魔术值，引发异常或在失败时返回false？

#1 楼

我不认为您的示例确实等效。有3个不同的组，每个组都有其行为依据。


当出现“直到”情况（例如StreamReader.Read）或简单时使用永远不会是有效答案的值（对于IndexOf，则为-1）。
当函数的语义是调用者确定它将起作用时，抛出异常。在这种情况下，不存在密钥或错误的双精度格式确实是例外。
如果语义是要探查是否可以进行操作，请使用out参数并返回布尔值。

对于情况2和3，您提供的示例非常清楚。对于神奇的价值，可以说这是否是一个好的设计决策，并非在所有情况下都是如此。

NaN返回的Math.Sqrt是一个特例-它遵循浮点标准。

#2 楼

您正在尝试与API用户进行交流。如果抛出异常，则没有任何强迫他们捕获的异常，只有阅读文档才能让他们知道所有可能的情况。就我个人而言，我发现在文档中查找某个方法可能引发的所有异常情况既缓慢又乏味（即使是在智能感知中，我仍然必须手动将其复制出来）。

值仍然需要您阅读文档，并可能参考一些const表来对该值进行解码。至少它没有所谓的非异常事件的例外开销。

这就是为什么即使有时不赞成使用out参数，我还是喜欢使用Try...的方法的原因句法。它是规范的.NET和C＃语法。您正在与API用户沟通，他们必须在使用结果之前检查返回值。您还可以在第二个out参数中添加有用的错误消息，这又有助于调试。这就是为什么我投票给带有参数解决方案Try...的out的原因。

然后，您的函数看起来正确，因为它仅具有输入参数，并且仅返回一件事。只是它返回的是一个元组。

实际上，如果您喜欢这种东西，则可以使用.NET 4中引入的新Tuple<>类。我个人不喜欢每个字段的含义不太明确的事实，因为我不能给Item1和Item2有用的名称。

#3 楼

如您的示例所示，每种情况都必须分别进行评估，并且在“特殊情况”和“流控制”之间存在相当大的灰度范围，尤其是如果您的方法旨在可重用并且可能以完全不同的方式使用比最初设计的要好。不要指望这里的所有人都同意“非例外”的含义，尤其是如果您立即讨论使用“例外”来实现这一点的可能性。该代码最容易阅读和维护，但我将假定图书馆设计者对此有清晰的个人见解，只需要在涉及的其他注意事项之间取得平衡即可。

简短答案

请遵循自己的直觉，除非您正在设计相当快速的方法，并期望有无法预料的重用。双向的异常；这使得这两种设计方法几乎相同，除了性能，调试器友好性和某些受限制的互操作性上下文之外。这通常归结为性能，因此，我们将重点放在性能上。


根据经验，期望抛出异常的速度比常规返回速度慢200倍（实际上，差异很大。）
根据另一条经验法则，与最原始的魔术值相比，抛出异常通常可以使代码更整洁，因为您不依赖程序员将错误代码转换为另一个错误代码，因为错误代码会通过多层客户端代码传递给另一个错误代码。有足够的上下文可以一致且适当地处理它的地方。 （特殊情况：null在这里往往表现得比其他魔术值更好，因为在某些但不是所有类型的缺陷的情况下，它倾向于自动将其自动转换为NullReferenceException;通常但并非总是如此，非常接近缺陷的来源缺陷。）

那么，教训是什么？

对于在应用程序生存期内（例如应用程序初始化）仅被调用过几次的函数，请使用任何能够您更清洁，更容易理解代码。不必担心性能。

要使用一次性函数，请使用任何可以使您的代码更简洁的东西。然后进行一些分析（如果需要的话），并根据度量或整体程序结构将异常更改为返回代码（如果它们属于可疑的最高瓶颈）。

对于昂贵的可重用函数，请使用任何能够您更干净的代码。如果您基本上总是必须进行网络往返或解析磁盘上的XML文件，则抛出异常的开销可能可以忽略不计。重要的是，不要丢失任何故障的细节，甚至是偶然的故障，要比从“非异常故障”更快地返回更为重要。

可重复使用的精益功能需要更多的考虑。通过使用异常，如果函数的主体执行得非常快，则您将使调用者的速度降低100倍，这些调用者将在一半（多次）调用中看到异常。例外仍然是一种设计选择，但是您将不得不为负担不起此费用的呼叫者提供一种开销较低的替代方法。让我们看一个例子。

您列出了Dictionary<,>.Item的一个很好的例子，从广义上讲，它从返回null的值更改为在.NET 1.1和.NET 2.0之间抛出KeyNotFoundException的情况（仅当您愿意考虑Hashtable.Item是其实用的非通用先行者）。这种“变化”的原因在这里并非没有兴趣。值类型的性能优化（不再装箱）使原始魔术值（null）成为不可选项； out参数只会带回一小部分性能成本。与抛出KeyNotFoundException的开销相比，后一种性能考虑可以忽略不计，但是异常设计在这里仍然是优越的。为什么？


ref / out参数每次都会产生成本，而不仅仅是在“失败”情况下。
任何在乎的人都可以在调用索引器之前先调用Contains，并且该模式完全自然地读取。如果开发人员想要但忘记调用Contains，则不会出现性能问题； KeyNotFoundException足够大，足以引起注意和修复。

#4 楼

在这种相对非常规的情况下，最好的办法是指示失败，为什么？


您不应允许失败。 />我知道，这有点易事和理想，但请听我说。在进行设计时，在许多情况下，您有机会偏爱没有故障模式的版本。 LINQ使用的where子句不会返回失败的'FindAll'，而只是返回一个空的可枚举值。让构造函数初始化该对象（或在检测到未初始化时进行初始化），而不是使用之前需要对其进行初始化的对象。关键是删除使用者代码中的故障分支。这是问题所在，因此请专注于此。从3.0开始，几乎在我开发的每个代码库中，都存在类似这种扩展方法的东西：
KeyNotFound具有类似的内置ConcurrentDictionary。

总而言之，有时总是无法避免的。这三者都有自己的位置，但是我倾向于第一种选择。尽管所有这些都是由null的危险造成的，但它是众所周知的，并且适合构成“非异常失败”集合的许多“未找到项目”或“结果不适用”方案。尤其是当您创建可为空的值类型时，“这可能会失败”的含义在代码中非常明确，难以忘记/增加。有点蠢。为您提供格式错误的字符串，尝试将日期设置为12月42日...您希望在测试过程中快速迅速地删除错误内容，以便识别并修复错误的代码。

最后一个选择是我越来越不喜欢的选择。输出参数很尴尬，并且在制定方法时倾向于违反一些最佳实践，例如专注于一件事而没有副作用。另外，外部参数通常仅在成功期间有意义。也就是说，它们对于通常受并发问题或性能考虑因素约束的某些操作（例如，您不想第二次访问数据库）至关重要。

如果返回值和out参数是不平凡的，因此首选Scott Whitlock关于结果对象的建议（例如Regex的GetOrAdd类）。

#5 楼

总是喜欢抛出异常。它在所有可能发生故障的功能之间具有统一的接口，并且它尽可能多地指示出故障-这是一个非常理想的属性。 。 Parse也可以返回值的事实确实有些正交。考虑一下您正在验证某些输入的情况。只要值是有效的，您实际上并不关心值是什么。提供一种TryParse功能没有错。但是它永远不能成为主要的操作模式。

#6 楼

正如其他人指出的那样，魔术值（包括布尔返回值）不是一个很好的解决方案，只是作为“范围结束”标记。原因：即使您检查对象的方法，语义也不是明确的。您必须实际阅读整个对象的完整文档，直到“哦，是的，如果它返回-42，则表示bla bla bla”。

出于历史原因或出于性能原因，可能会使用此解决方案，但应避免使用此解决方案。 br />这里的经验法则是，程序不应对异常做出反应，除非程序/无意/违反了某些条件。应该使用探测来确保不会发生这种情况。因此，异常要么意味着没有事先执行相关的探测，要么发生了完全出乎意料的事情。

示例：给定的路径。

您应该使用File对象预先评估该路径对于创建或写入文件是否合法。到非法或其他不可写的路径，您应该得到一个摘录。这可能是由于争用情况而发生的（某些问题，在您有问题后，其他用户已删除目录或将其设置为只读）。如果条件适合进行预先操作（探测），通常将采用不同的结构，因此应使用不同的机制。

#7 楼

我认为Try模式是最好的选择，当代码仅指示发生了什么时。我讨厌参数，喜欢可为空的对象。我创建了以下类

public sealed class Bag<TValue>
{
    public Bag(TValue value, bool hasValue = true)
    {
        HasValue = hasValue;
        Value = value;
    }

    public static Bag<TValue> Empty
    {
        get { return new Bag<TValue>(default(TValue), false); }
    }

    public bool HasValue { get; private set; }
    public TValue Value { get; private set; }
}

，所以我可以编写以下代码

    public static Bag<XElement> GetXElement(this XElement element, string elementName)
    {
        try
        {
            XElement result = element.Element(elementName);
            return result == null
                       ? Bag<XElement>.Empty
                       : new Bag<XElement>(result);
        }
        catch (Exception)
        {
            return Bag<XElement>.Empty;
        }
    }

看起来像可空但不仅适用于值类型

另一个示例

    public static Bag<string> TryParseString(this XElement element, string attributeName)
    {
        Bag<string> attributeResult = GetString(element, attributeName);
        if (attributeResult.HasValue)
        {
            return new Bag<string>(attributeResult.Value);
        }
        return Bag<string>.Empty;
    }

    private static Bag<string> GetString(XElement element, string attributeName)
    {
        try
        {
            string result = element.GetAttribute(attributeName).Value;
            return new Bag<string>(result);
        }
        catch (Exception)
        {
            return Bag<string>.Empty;
        }
    }

#8 楼

如果您对“魔术值”路线感兴趣，那么解决此问题的另一种方法是重载Lazy类的目的。尽管Lazy旨在推迟实例化，但并没有真正阻止您使用Maybe或Option的方法。例如：

    public static Lazy<TValue> GetValue<TValue, TKey>(
        this IDictionary<TKey, TValue> dictionary,
        TKey key)
    {
        TValue retVal;
        if (dictionary.TryGetValue(key, out retVal))
        {
            var retValRef = retVal;
            var lazy = new Lazy<TValue>(() => retValRef);
            retVal = lazy.Value;
            return lazy;
        }

        return new Lazy<TValue>(() => default(TValue));
    }