时间戳

首页 > 解决方案 > 不可变（纯函数）上下文中的 UnsupportedOperationException 与 IllegalStateException

java - 不可变（纯函数）上下文中的 UnsupportedOperationException 与 IllegalStateException

问题描述

问题IllegalStateException vs UnsupportedOperationException涵盖了何时应该使用一个与另一个的一般情况。我完全同意 davidxxx 接受的答案，因为这是我一直使用的方式：

UnsupportedOperationException 应该使用，因为该方法根本不支持，而 IllegalStateException 应该使用，因为该方法受支持，但在当前状态下，它是不合法的。

然而，在函数式编程中，这种区别变得非常模糊：通常，在命令式 OO 语言中，“根本不支持”是根据多态子类来理解的。在函数式语言中，即使支持 OO 编程并将类作为代码单元，它们传统上相对于实例化过程的权重略小。如果一个对象是不可变的，并且某个操作不能在任何时候完成，它永远不会，这与在 OO 语言中接收更具体的类的实例并没有太大区别。同时，文档中提到的“应用状态”的概念IllegalStateException仍然存在，但我发现它在该单个对象的上下文中有些误导，并且在函数式语言中有点不合适。也就是说，看到UnsupportedOperationException抛出的用户可能会遵循Java策略并假设在任何情况下都不能在给定类上调用该方法。

我知道它在一定程度上通常是基于意见的，所以我想特别问一下，Scala和F#的标准库之间是否存在使用共识，或者是大型、广泛使用的 OS 项目设置的先例？我想确定一个单一的、定义明确的方案，该方案遵循最不意外的政策。

标签： javascalaexceptionf#

解决方案

在 F# 中，从 .Net 异常到您的两个最接近的异常是 InvalidOperationException 和 NotSupportedException。

Option/Result 类型和模式匹配的使用强制编译时检查，以便好的设计不会抛出这些异常。那是像 F# 这样的强类型静态类型语言不应该抛出这些异常（除了在与 .Net 库互操作时处理它们被抛出）

推荐阅读