在 Java 中扩展 Throwable

Question

Java 允许您创建一个全新的 Throwable 子类型，例如：

public class FlyingPig extends Throwable { ... }

现在，很少，我可能会做这样的事情：

throw new FlyingPig("Oink!");

当然还有其他地方：

try { ... } catch (FlyingPig porky) { ... }

我的问题是：

• 这是吗？一个坏主意？如果是这样，为什么？
  • 如果这是一个坏主意，可以采取什么措施来防止这种子类型化？
  • 既然它是无法预防的（据我所知），那么会导致什么灾难？
• 如果这不是一个坏主意，为什么不呢？
  • 如何利用扩展 Throwable 来创造有用的东西？

---

建议的场景#1

我真的想要做这样的事情的场景具有以下属性：

• “事件”是最终发生的事情。这是预期。它绝对不是Error，并且当它发生时也没有任何Exception-al。
  • 因为它是预期的，所以会有一个catch在等待它。它不会“滑过”任何东西。它不会“逃避”任何捕获常规异常和/或错误的尝试。
• “事件”发生的情况极其罕见。
• 当发生这种情况时，通常会有很深的堆栈跟踪。

所以现在我想说的也许已经很清楚了：FlyingPig 是详尽递归搜索的结果。

要搜索的对象是存在的：只需在搜索空间的大海中找到它即可。搜索过程将是一个漫长的过程，因此相对昂贵的异常处理成本可以忽略不计。事实上，使用布尔 isFound 标志的传统控制流构造替代方案可能更昂贵，因为必须在整个搜索过程中（很可能在递归的每个级别）不断检查它。该检查在 99.99% 的情况下都会失败，但传播终止条件是绝对必要的。在某种程度上，虽然检查有效，但检查效率低下！

当找到所寻找的对象时，只需抛出-ing一个FlyingPig，您就不必因为boolean isFound的管理而使代码变得混乱> 旗帜。在这方面，代码不仅更干净，而且由于这一省略，它可能运行得更快。

总而言之，可以在这两者之间进行选择：

• 传统的控制流方法
  • 使用布尔值isFound，连续检查
  • 99.99% 的情况下，支票是“浪费”，因为它仍然是假
  • 当它最终变为true时，您将停止递归，并且必须确保可以正确展开到初始调用。
• FlyingPig 方法
  • 不用理会任何 boolean isFound。
  • 如果找到，只需抛出 new FlyingPig()；这是预期的，因此会有一个catch。
  • 不管理 boolean 标志，如果需要继续，则不会浪费检查，无需簿记来手动展开递归等。

问题：

• 这种（ab）使用异常的技术有效吗？ （有名字吗？）
• 如果有效，应该 FlyingPig extends Throwable，还是 Exception 就可以了？ （尽管它的情况没有什么异常？）

Answer 1

我想说这是一个非常糟糕的主意。许多代码的实现都是基于这样的假设：如果您捕获了 Error 和 Exception，那么您就捕获了所有可能的异常。大多数教程和教科书都会告诉你同样的事情。通过创建 Throwable 的直接子类，您可能会产生各种维护和互操作性问题。

我想不出有什么充分的理由来扩展 Throwable。改为扩展 Exception 或 RuntimeException。

编辑 - 回应OP提出的场景#1。

异常是处理“正常”流量控制的一种非常昂贵的方法。在某些情况下，我们谈论的是执行数千条额外指令来创建、抛出和捕获异常。如果您打算忽略公认的智慧并使用异常进行非异常流程控制，请使用 Exception 子类型。试图通过将 is 声明为 Throwable 的子类型来假装某件事是“事件”而不是“异常”，不会取得任何成果。

然而，将异常与错误、错误、错误等等混为一谈是错误的。使用Exception 的子类表示“不是错误、差错、错误或其他任何内容的异常事件”没有什么问题。关键是该事件应该例外；即不寻常，很少发生，...

总之，FlyingPig 可能不是错误，但这没有理由不将其声明为 Exception 的子类型代码>.

Answer 2

这种（ab）使用异常的技术有效吗？ （有名字吗？）

在我看来，这不是一个好主意：

• 它违反了 原则至少令人惊讶的是，它使代码更难阅读，尤其是在没有任何异常情况的情况下。
• 在 Java 中抛出异常是一个非常昂贵的操作（尽管在这里可能不是问题）。

异常应该不用于流量控制。如果我必须命名这种技术，我会称之为代码味道或反模式。

另请参阅：

• 抛出异常来控制流程 - 代码异味？

如果有效，FlyingPig 应该扩展 Throwable，还是 Exception 就可以了？ （即使它的情况没有什么异常？）

某些情况下，您可能希望catch Throwable 而不仅仅是捕获Exception 但也有 Error，但这种情况很少见，人们通常不会捕获Throwable。但我未能找到您想要抛出 Throwable 子类的情况。

而且我还认为，扩展 Throwable 并不会让事情看起来不那么“异常”，反而会让事情看起来更糟——这完全违背了初衷。

所以总而言之，如果你真的想抛出一些东西，那就抛出Exception的子类。

另请参阅：

• 什么时候应该使用 Throwable 而不是 new Exception？< /a>

Answer 3

以下是 HotSpot 架构师 John Rose 的博客文章：

http://blogs.oracle.com /jrose/entry/longjumps_considered_inexpense

它是关于“滥用”流量控制的异常。用例略有不同，但是..
简而言之，如果您预先分配/克隆异常以防止创建堆栈跟踪，那么它的效果非常好。

我认为如果对客户“隐藏”这种技术是合理的。
IE，你的 FlyingPig 应该永远无法离开你的库（所有公共方法都应该传递保证不抛出它）。保证这一点的一种方法是使其成为受检查的异常。

我认为扩展 Throwable 的唯一理由是因为您希望允许人们传入具有 catch(Exception e) 子句的回调，并且您希望他们忽略您的结果。我刚好可以买那个...

Answer 4

org.junit.Test 注释包含 None 类，它扩展了 Throwable 并用作 expected 的默认值代码>注释参数。

Answer 5

如果您可以证明 FlyingPig 与 Error 和 Exception 不同的原因是什么，以至于它不适合作为其中任何一个的子类，那么创建它并没有什么根本性的错误。

我能想到的最大问题是在务实的世界中，有时有正当理由要捕获java.lang.Exception。你的新类型的 throwable 将直接飞过 try-catch 块，这些块具有抑制（或记录、包装等）每个可能的非致命问题的合理期望。

另一方面，如果您正在对一个不合理地抑制 java.lang.Exception 的旧系统进行维护，那么您可以绕过它。 （假设真诚地呼吁时间来实际正确修复它被拒绝）。

Answer 6

随着这个问题的发展，我明白了
我误解了要点
原来的问题，所以一些
其他答案可能更多
相关的。我会保留这个答案
在这里，因为它可能仍然有帮助
其他有类似问题的人，
并在搜索时找到此页面
他们的问题的答案。

扩展 Throwable 使其能够抛出（和处理）自定义异常并没有什么问题。但是，您应该记住以下几点：

• 使用尽可能最具体的异常是一个好主意。它将允许调用者以不同的方式处理不同类型的异常。记住异常的类层次结构很重要，因此您的自定义异常应该扩展另一种尽可能接近您的异常的 Throwable 类型。
• 扩展 Throwable 可能级别太高。尝试扩展 Exception 或 RuntimeException （或者更接近引发异常的原因的较低级别异常）。请记住 RuntimeException 和 Exception 之间的区别。
• 对引发异常（或异常的子类）的方法的调用需要包装在能够处理异常的 try/catch 块中。当您预计由于情况可能超出您的控制（例如，网络出现故障）而出现问题时，这非常有用。
• 对抛出 RuntimeException（或其子类）的方法的调用不需要包装在可以处理异常的 try/catch 块中。 （当然可以，但不需要。）这更多的是针对确实不应该预期的异常。

因此，假设您的代码库中有以下异常类：

public class Pig extends Throwable { ... }
public class FlyingPig extends Pig { ... }
public class Swine extends Pig { ... }
public class CustomRuntimeException extends RuntimeException { ... }

和一些方法

public void foo() throws Pig { ... }
public void bar() throws FlyingPig, Swine { ... }
// suppose this next method could throw a CustomRuntimeException, but it
// doesn't need to be declared, since CustomRuntimeException is a subclass
// of RuntimeException
public void baz() { ... } 

现在，您可以有一些调用这些方法的代码，如下所示：

try {
    foo();
} catch (Pig e) {
    ...
}

try {
    bar();
} catch (Pig e) {
    ...
}

baz();

请注意，当我们调用 bar() 时，我们可以捕获 Pig，因为 FlyingPig 和 Swine 都扩展了 Pig。如果您想要执行相同的操作来处理任一异常，这非常有用。但是，您可以以不同的方式处理它们：

try {
    bar();
} catch (FlyingPig e) {
    ...
} catch (Swine e) {
    ...
}

Answer 7

玩吧！框架使用类似的东西来处理请求。请求处理经过许多层（路由、中间件、控制器、模板渲染），在最后一层渲染的 HTML 为 包裹在一个 throwable 中并抛出，最顶层捕获、解开并发送到客户。因此，涉及的许多层中的方法都不需要显式返回响应对象，也不需要将响应对象作为参数传递以进行传播和修改。

我对细节有点粗略。你可以看一下Play的代码！框架的细节。