Question

我们目前正在设计用于存储设置的API，我们正在考虑使用这两种方法：

public Object getSetting(String key) {
    // return null if key does not exist
}

public Object getSettingExc(String key) {
    // throw a runtime exception if key does not exist
}

不知怎的，我觉得这不对，但我想不出任何缺点，除了加倍API中的函数数量，可能会降低代码的可读性（如果我知道设置必须存在，我想我应该显式抛出异常而不是依赖于get方法。

您对此有何看法？

Answer 1

当代码无法根据其公布的功能继续运行时，异常出现的例外情况。

请求未设置的设置几乎不值得例外。如果“你”（即调用代码）“知道”设置“必须”存在，请调用getSetting()，检查null的返回值，然后然后你应该在那里知道自己抛出异常。添加有关未找到上下文的设置的有意义消息。（这只是来电者知道的事情。）

不要将异常的抛出委托给不知道查询或的上下文的代码，该设置 >那里，需要明确告知（通过以不同的名称进行调用）。另外，getSettingExc()很可能只是getSetting()周围的空检查和抛出包装器，所以为什么不在可以使异常消息更有帮助的地方进行呢？ / p>

IMHO。（这就是我意识到我应该投票而不是写一个答案的地方......）

Answer 2

这引入了对象结构和潜在错误条件之间的奇怪耦合。关于你的评论：

我只是试图收集论据来说服我团队中的其他人。

责任应该在这个设计的支持者上，以证明它是合理的，而不是你的理由反对它。在我见过的任何设计中，没有其他人使用它。

这确实但是让我想起了另一种可能的设计是你的团队的意图吗？考虑以下两种方法：

public Object getSetting(String key) {
    // return the setting or throw an exception
}

public Object getSettingOrDefault(String key) {
    // return the setting or a pre-determined default
}

这使方法更多地与功能对齐而不是与错误条件对齐。 getSetting()可以宣传它可能会抛出异常，而getSettingOrDefault()可以宣告如果在设置中找不到任何异常，它将默认为特定值。

如果Java具有可选参数或类似的参数，getSettingOrDefault()甚至可以接受默认值作为参数，以便在没有此类设置的情况下使用。虽然这可能会让消费代码变得有点麻烦，只是在那个问题上大声思考。

无论哪种方式，API都应该反映功能而不是错误条件。 理想情况下应该只有一种方法，但是如果明显需要区分抛出的方法和不具备的方法（我当然可以看到这种情况）在具有已检查异常的语言中，这两者应与功能对齐，而不是与例外对齐。

Answer 3

恕我直言，有两种方法可以完全相同的操作，这表明你作为API设计师没有完成“设计”你的API的工作。选择这种或那种方式，通过API（javadocs）进行宣传，然后消费者的使用方式（一种或另一种）保持一致。

重载方法而不抛出反模式的异常？

3 个答案: