Java 如果理论规定使用选中异常，我是否应该使用相关的内置未选中异常？

关于“检查与未检查的异常”主题，有相当多的帖子。可能是最全面、最翔实的。然而，我仍然无法遵循这里提出的逻辑，这是有原因的

我正在围绕一组彼此相似的服务构建一个包装器API。但是，它们之间存在微小的差异（或者将来可能存在这种差异），因此某些功能（次要和快捷性质）可能由某些服务支持，而不由其他服务支持。因此，采用以下方法似乎是合乎逻辑的：

public interface GenericWrapperInterface {
    void possiblyUnsupportedOperation () throws java.lang.UnsupportedOperationException;
}

为什么

不支持操作异常

？因为它是专为这种情况设计的

但是，除Oracle之外，所有相关SO帖子都假设，如果使用异常来表示客户可以从中恢复的问题，或者是可预测但不可避免的问题，则该异常应为已检查异常。我的案例符合这些要求，因为对于某些操作，可能会提前知道其不可用的可能性，并且这些操作并不重要，如果需要，可以避免

---

所以我迷失在这个难题中。我是否应该使用一个完全合适的标准异常并违反异常使用的一般逻辑，或者我应该构建自己的检查替代方案，从而复制代码并在API用户中造成额外的混乱？

经验法则是，未检查的异常表示程序员错误，检查的异常表示情况。因此，作为API的作者，您必须决定是否应该事先由程序员阻止异常情况，或者是否应该要求程序员在异常情况发生后处理异常情况。

特别是，“UnsupportedOperationException”表示Java OO模型失败，违反了利斯科夫的原则

通常，这意味着您的代码有其他非OO方法来决定是否应该调用所讨论的方法：

if (instance.isSupportive()) instance.possiblyUnsupportedOperation();

---

因此，调用一个未实现的方法是一个逻辑错误，与断言失败、堆栈溢出或内存耗尽一致。因此，它不应该是选中的异常。

我明白你的意思。但是，假设该接口有大量的方法，这些方法可能被支持，也可能不被支持。为它们中的每一个创建一个单独的测试方法，或者将这些方法映射到某个枚举上，以将方法描述符传递到测试程序函数中——这不是一个更丑陋的代码解决方案吗？毕竟，即使是来自Collections框架的Java核心类也使用

UnsupportedOperationException

来指示特定容器是否可以使用特定操作。既然Java本身已经是不完美的，我不应该遵循它自己的规则吗？如果您希望常规调用不可用的方法，并使用异常作为一种带外返回值，那么您的设计就比我想象的更离谱了。在这种情况下，请使用其他一些选中的异常，而不是

UnsupportedOperationException

。考虑集合框架中的

UnsupportedOperationException

：其使用的一个示例是修改不可修改集合中的方法。在这种情况下，您不需要盲目地添加一个元素—尝试在

UnmpodifiableList

上调用add（）将是一个逻辑错误。你的情况似乎不同。请检查您的OO设计……如果事先知道该操作不受支持，则调用该操作将引发未经检查的异常，因为这是一个不应该发生的编程错误。@ZhongYu，客户端代码可能知道缺少支持的可能性，但在运行时之前，每个特定的实现对象是否具有这种支持可能是未知的。