在这里抛出异常是一种反模式吗？

代码审查后，我刚刚讨论了设计选择。我想知道您的意见是什么。

有一个此类Preferences，它是键-值对的存储桶。空值是合法的（这很重要）。我们希望某些值可能尚未保存，并且我们希望通过在请求时使用预定义的默认值对其进行初始化来自动处理这些情况。

讨论的解决方案使用以下模式（注意：显然，这不是实际的代码-出于说明目的而进行了简化）：

public class Preferences {
    // null values are legal
    private Map<String, String> valuesFromDatabase;

    private static Map<String, String> defaultValues;

    class KeyNotFoundException extends Exception {
    }

    public String getByKey(String key) {
        try {
            return getValueByKey(key);
        } catch (KeyNotFoundException e) {
            String defaultValue = defaultValues.get(key);
            valuesFromDatabase.put(key, defaultvalue);
            return defaultValue;
        }
    }

    private String getValueByKey(String key) throws KeyNotFoundException {
        if (valuesFromDatabase.containsKey(key)) {
            return valuesFromDatabase.get(key);
        } else {
            throw new KeyNotFoundException();
        }
    }
}

它被批评为控制流的反模式滥用异常。KeyNotFoundException-仅针对该用例而生-永远不会超出此类范围。

从本质上讲，这是两种使用fetch进行获取信息的方法。

数据库中不存在的密钥并不令人担忧或例外-我们希望每当添加新的首选项设置时都会发生这种情况，因此，如果需要，可以使用默认值优雅地对其进行初始化的机制。

与此相反的是getValueByKey-私有方法-因为现在定义具有告知公众对方法没有自然的方式，这两种价值，关键是否在那里。（如果不是，则必须添加它，以便可以更新值）。

返回值null是模棱两可的，因为这null是完全合法的值，因此无法确定它是否意味着密钥不存在，或者是否存在null。

getValueByKey将必须返回某种a Tuple<Boolean, String>，如果密钥已经存在，则将bool设置为true，以便我们可以区分(true, null)和(false, null)。（out可以在C＃中使用参数，但这是Java）。

这是更好的选择吗？是的，您必须定义一些一次性使用的类以达到的效果Tuple<Boolean, String>，但随后我们将摆脱KeyNotFoundException，从而实现了这种平衡。我们也避免了处理异常的开销，尽管它在实际意义上并不重要-无需考虑性能方面的考虑，它是客户端应用程序，也不像每秒会检索用户偏好数百万次。

这种方法的一种变体可以使用Guava Optional<String>（在整个项目中已经使用了Guava）而不是一些自定义方法Tuple<Boolean, String>，然后我们就可以区分Optional.<String>absent()“适当”了null。但是，由于易于理解的原因，它仍然让人感到有些呆滞-引入两个“空”级别似乎首先滥用了创建Optionals 背后的概念。

另一个选择是显式检查密钥是否存在（添加boolean containsKey(String key)方法并getValueByKey仅在我们已经断言它存在的情况下调用）。

最后，也可以内联私有方法，但是实际方法getByKey比我的代码示例复杂一些，因此内联会使它看起来很讨厌。

我可能会在这里分开，但我很好奇在这种情况下您会押宝于最佳实践。我在Oracle或Google的风格指南中找不到答案。

使用代码示例中的异常是一种反模式，还是因为替代方法不是很干净？如果是，在什么情况下可以？反之亦然？

是的，您的同事是对的：那是错误的代码。如果错误可以在本地处理，则应立即处理。不应引发异常，然后立即处理异常。

这比您的版本干净得多（该getValueByKey()方法已删除）：

public String getByKey(String key) {
    if (valuesFromDatabase.containsKey(key)) {
        return valuesFromDatabase.get(key);
    } else {
        String defaultValue = defaultValues.get(key);
        valuesFromDatabase.put(key, defaultvalue);
        return defaultValue;
    }
}

仅当您不知道如何在本地解决错误时，才应引发异常。

我不会将这种异常的使用称为反模式，不是解决复杂结果传递问题的最佳解决方案。

最好的解决方案（假设您仍使用Java 7）是使用Guava的Optional；我不同意在这种情况下使用它会有点黑。在我看来，基于番石榴对Optional的扩展解释，这是何时使用它的完美示例。您要区分“找不到值”和“找到空值”。

由于没有性能方面的考虑，并且它是一个实现细节，因此最终选择哪个解决方案都没有关系。但是我必须同意这是不好的风格。缺席的关键是您将要发生的事情，您甚至最多只能处理一次调用堆栈，这是异常处理最有用的地方。

元组方法有点笨拙，因为当布尔值为假时，第二个字段是无意义的。事先检查密钥是否存在是很愚蠢的，因为地图两次查找了密钥。（嗯，您已经在做，所以在这种情况下是三次。）该Optional解决方案非常适合该问题。这似乎有点讽刺意味，以存储null在Optional，但如果这是用户想要做什么，你不能说没有。

正如Mike在评论中指出的那样，这是有问题的。Guava和Java 8都Optional不允许存储null。因此，您需要自己动手制作（虽然简单易行），但涉及大量样板，因此对于只在内部使用一次的内容来说可能会过分杀伤力。您也可以将地图的类型更改为Map<String, Optional<String>>，但处理Optional<Optional<String>>s会很麻烦。

一个合理的折衷办法可能是保留异常，但要承认其作为“替代回报”的作用。创建一个禁用堆栈跟踪的新检查异常，并抛出一个预先创建的实例，您可以将该实例保存在静态变量中。这很便宜- 可能和本地分支一样便宜 -并且您不能忘记处理它，因此缺少堆栈跟踪不是问题。

有一个Preferences类，它是键-值对的存储桶。空值是合法的（这很重要）。我们希望某些值可能尚未保存，并且我们希望通过在请求时使用预定义的默认值对其进行初始化来自动处理这些情况。

问题就是这样。但是您已经自己发布了解决方案：

这种方法的一种变体可以使用Guava的Optional（在整个项目中已经使用了Guava）而不是一些自定义的Tuple，然后我们可以区分Optional.absent（）和“ proper” null。但是，由于易于理解的原因，它仍然让人感到有些呆滞-引入两个“无效”级别似乎滥用了最初创建Optionals背后的概念。

但是，请勿使用null 或 Optional。您可以并且应该Optional仅使用。对于您的“骇客”感觉，只需嵌套使用它，这样一来，您Optional<Optional<String>>就可以清楚地知道数据库中可能有一个键（第一个选项层），并且它可能包含预定义的值（第二个选项层）。

这种方法比使用异常更好，并且只要Optional您不陌生，就很容易理解。

另外请注意，它Optional具有一些舒适功能，因此您不必自己完成所有工作。这些包括：

• static static <T> Optional<T> fromNullable(T nullableReference)将您的数据库输入转换为Optional类型
• abstract T or(T defaultValue) 获取内部选项层的键值或（如果不存在）获取默认键值

我知道我迟到了，但是无论如何，您的用例都类似于Java的Properties让我们也定义一组默认属性的方式，如果实例没有加载相应的密钥，则会检查这些默认属性。

看一下如何实现Properties.getProperty(String)（从Java 7开始）：

Object oval = super.get(key);
String sval = (oval instanceof String) ? (String)oval : null;
return ((sval == null) && (defaults != null)) ? defaults.getProperty(key) : sval;

正如您所引用的，确实没有必要“滥用异常来控制流程”。

@BЈовић的答案也可以使用类似但更简洁的方法：

public String getByKey(String key) {
    if (!valuesFromDatabase.containsKey(key)) {
        valuesFromDatabase.put(key, defaultValues.get(key));
    }
    return valuesFromDatabase.get(key);
}

尽管我认为@BЈовић的答案很好，以防万一getValueByKey，在其他地方都不需要的情况下，但如果程序包含两个用例，我认为您的解决方案不是很糟糕：

• 如果事先不存在密钥，则通过自动创建的密钥进行检索，并且

• 在没有这种自动性的情况下进行检索，而不更改数据库，存储库或键映射中的getValueByKey任何内容（认为​​是公开的，而不是私有的）

如果这是您的情况，并且只要性能达到可接受的水平，那么我认为您提出的解决方案是完全可以的。它具有避免重复检索代码的优点，它不依赖于第三方框架，并且非常简单（至少在我看来）。

实际上，在这种情况下，丢失的密钥是否为“例外”情况取决于上下文。对于实际情况，getValueByKey需要类似的东西。对于需要自动创建密钥的情况，提供一种方法，该方法可以重用已经可用的功能，吞噬异常并提供不同的失败行为，这是很有意义的。这可以解释为的扩展或“修饰符” getValueByKey，而不是“控制流滥用了异常”的功能。

当然，还有第三种选择：创建第三个私有方法，返回Tuple<Boolean, String>您所建议的，并在getValueByKey和中重用此方法getByKey。对于更复杂的情况，可能确实是更好的选择，但对于此处所示的简单情况，恕我直言，这有点工程过度的感觉，我怀疑代码是否真的可以这样维护。我在这里是Karl Bielefeldt的最高回答：

“在简化代码时，您不应该对使用异常感到难过”。

Optional是正确的解决方案。但是，如果您愿意，可以选择一种哨兵，它具有较少的“两个零”的感觉。

定义一个私有静态字符串keyNotFoundSentinel，其值为new String("")。*

现在，私有方法可以return keyNotFoundSentinel而不是throw new KeyNotFoundException()。公用方法可以检查该值

String rval = getValueByKey(key);
if (rval == keyNotFoundSentinel) { // reference equality, not string.equals
    ... // generate default value
} else {
    return rval;
}

实际上，null是哨兵的特例。它是由语言定义的标记值，具有一些特殊行为（即，如果在上调用方法，则行为良好null）。就像几乎几乎所有语言都使用过这样的哨兵一样，它是如此有用。

*我们有意使用new String("")而不是仅仅""用于防止Java“中断”字符串，这将为它提供与任何其他空字符串相同的引用。因为执行了此额外步骤，我们可以确保引用的String keyNotFoundSentinel是唯一的实例，我们需要确保它永远不会出现在地图本身中。

从从所有Java痛点中学到的框架中学习：

.NET为解决此问题提供了两种更为完善的解决方案，例如：

• Dictionary<TKey, TValue>.TryGetValue(TKey, out TValue)
• Nullable<T>.GetValueOrDefault(T default)

后者很容易用Java编写，而前者只需要一个“强引用”帮助程序类。