exception - 设计一种带有检查异常的语言

Question

我很清楚关于检查异常是否是一个好主意的整个争论，我站在它们的一边……但这不是这个问题的重点。我正在设计一个相当简单的编译型 OOP 语言，我决定基本上使用检查异常作为返回错误的一种方式，而不是沿着返回错误代码的 C 路线。

我正在寻找有关如何改进已检查异常的 Java 模型以消除它们的大部分不利方面的一些见解，也许是语法更改或稍微更改实际功能。对受检异常的主要批评之一是懒惰的程序员可能会吞下它们，因此不会出现错误。

也许捕获异常可能是可选的，因此如果没有捕获异常，程序就会崩溃？或者可能有特定的符号来表示未处理异常(如 C++ 虚拟函数“= 0”符号)？或者，如果异常处理程序为空，我什至可能导致程序崩溃(尽管这可能会让不熟悉该语言的程序员感到惊讶)？

try...catch 语法如何，您认为可以有更简洁的方式来表达正在捕获异常吗？该语言将使用垃圾收集器，很像 Java，所以是否需要 finally 子句？最后，检查异常还有哪些其他缺点以及存在哪些潜在的解决方案(如果有)？

Answer 1

Checked Exceptions 只是 Erik Meijer 所说的类型诚实的更普遍驱动的一个小例子。 IE。过程、方法、函数不应该取决于它们的类型。如果你看到一个类型签名，你应该能够信任它的类型。
对于今天的 Java 来说，情况并非如此(尤其是当您想象一个没有检查异常的 Java 时)。
如果您在 Java 中有这样的类型签名:

Foo bar(Baz)

它说“我将 Baz 作为输入并产生一个 Foo 作为输出”。但那是谎言。
其实，bar需要一个 Baz或 null作为输入。它还以整个全局状态、类状态和实例状态以及整个宇宙作为输入(通过例如文件 I/O、网络 I/O、数据库 I/O 等)。并且它不会产生 Baz作为输出:它产生一个 Foo或 null或异常或 Bottom (即什么都没有)。此外，它的输出还包括整个全局状态、整个类状态、整个实例状态以及整个宇宙的状态。bar的实际类型是:

(IO<Foo | null | Exception> | Bottom) bar(IO<Baz | null>)

或类似的东西。
这需要修复，Checked Exceptions 是其中的一个(非常小的)部分。我个人认为其他部分更重要，Java 设计人员应该专注于修复这些而不是异常(特别是因为异常只是副作用，所以当您修复副作用时，实际上几乎可以自动免费修复异常 -效果)。
无论如何，这就是为什么我相信 Checked Exceptions 背后的总体想法是一件好事™，即使在 Java 中的具体实现可能有点麻烦。
如何修复 Checked Exceptions 在很大程度上取决于您认为它们实际上有什么问题。
有些人认为 Checked Exceptions 的问题在于，当您更改方法的内部实现以使用与以前不同的辅助方法时，这会引发与旧方法不同的异常集，您需要显式处理这些异常异常(exception)或声明它们，从而破坏您的所有客户。现在，如果您认为 Checked Exceptions 是错误的，那么只有一种方法可以解决它们:首先不要使用它们。更改您抛出的异常是 API 契约(Contract)中的重大更改，而 API 契约(Contract)中的重大更改应该会破坏客户端代码。 (或者更准确地说:您不应该对 API 契约(Contract)进行重大更改，以免破坏客户端代码。)
我认为 Java 实现的 Checked Exceptions 的主要问题是它们破坏了异常的主要特性之一:非本地错误处理。一个错误在这里发生，在那里被处理，这两个是唯一需要知道的。如果这里可能发生不同类型的错误，那么唯一需要了解该新错误且唯一需要更改的地方就是那里的错误处理程序。
使用 Java 实现的检查异常，中间的每一段代码也需要更改。
解决此问题的一项建议是 Anchored Exception Declarations . (在 Modular Anchored Exception Declarations 中改进。)
anchor 定异常声明的想法基本上是为异常声明使用委托(delegate)，就像在方法体中使用委托(delegate)一样，毕竟这是首先产生问题的原因。
假设您有一些委托(delegate)给另一种方法的文件读取器方法:

String fileReader(String filename) {
  return this.fileHelper.read(filename);
}

现在你进入 JavaDoc for FileHelper#read并将异常(exception)列表剪切并粘贴到您的方法中:

String fileReader(String filename) throws IOException, CustomFileReaderEx

现在作者FileHelper#read决定他使用不同的实现策略。现在，他首先确保文件存在、可以打开并且格式正确，从而确保实际文件读取永远不会失败。因此，自然而然地，异常集会发生变化。不再可能获得 IOException或 CustomFileReaderEx .相反，您可以获得 InvalidFilenameEx或 CorruptDataEx .所以，你再次剪切和粘贴:

String fileReader(String filename) throws InvalidFilenameEx, CorruptDataEx

不仅你必须做出改变，其他所有拨打 fileReader 的人都必须做出改变。 (以及每个调用他们的人和每个调用他们的人……)也是如此。太疯狂了!您将调用委托(delegate)给 fileHelper 的原因首先是这样你就不必关心这些细节。
因此， anchor 定异常声明的想法是将这个委托(delegate)用于异常声明本身。与其说你抛出了哪些精确的异常，你只是责怪别人。 “他做到了!”:

String fileReader(String filename) throws like this.fileHelper.read

你的客户只会说:

Foo whatever() throws like fileReader

这样，当 FileHelper改变它的异常，那么唯一需要改变的代码就是最顶层的异常处理代码，就像我上面描述的 unchecked 情况一样。
当然，也有限制。例如，为了不破坏封装，您只能在 throws like 中使用标识符。所有客户都可以访问的条款。如果，在这种情况下，fileHelper是 private领域，你不能使用它。你需要一些其他的方式。例如，如果 FileHelper类(class)是 public (或者如果它是私有(private)包并且您的所有客户都住在同一个包中)，您可以改为说

String fileReader(String filename) throws like FileHelper.read

论文中还列出了其他限制。 (其中之一在模块化 anchor 定异常声明文件中被解除。)
无论如何，这是改善 Checked Exceptions 的一些问题的一种方法。然而，Checked Exceptions 已经存在将近 40 年了，我们仍然没有弄清楚它们，所以这显然是一个难题。