在 Java 中扩展 Throwable

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

public class FlyingPig extends Throwable { ... }

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

throw new FlyingPig("Oink!");

当然还有其他地方：

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

我的问题是：

• 这是个坏主意吗？如果是这样，为什么？
  • 如果这是一个坏主意，可以做些什么来防止这种子类型化？
  • 既然这是不可预防的（据我所知），可能导致什么灾难？
• 如果这不是一个坏主意，为什么不呢？
  • 你怎么能从你能做到的事实中做出一些有用的东西？extends Throwable

建议方案 #1

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

• “事件”是最终会发生的事情。这是意料之中的。它绝对不是一个，当它发生时，也没有什么-al。ErrorException
  • 因为它是预期的，所以会有一个等待它。它不会“滑过”任何东西。它不会“逃避”任何一般和/或.catchcatchExceptionError
• “事件”很少发生。
• 当它发生时，通常会有一个很深的堆栈跟踪。

因此，也许现在很清楚我想说的是：是详尽的递归搜索的结果。FlyingPig

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

通过在找到所搜索的对象时简单地 -ing a，您不必将代码与标志的管理混为一谈。代码不仅在这方面更干净，而且由于这种遗漏，它可能会运行得更快。throwFlyingPigboolean isFound

因此，总而言之，选择是在以下两者之间：

• 传统的控制流方法
  • 使用 ，已连续检查boolean isFound
  • 99.99%的时间，支票是一种“浪费”，因为它仍然是false
  • 当它最终变成 时，你停止递归，你必须确保你可以正确地放松到最初的调用。true
• FlyingPig方法
  • 不要打扰任何.boolean isFound
  • 如果找到，只需 ;这是意料之中的，所以会有一个。throw new FlyingPig()catch
  • 没有标志的管理，如果你需要继续前进，没有浪费的支票，没有簿记来手动解除递归，等等。boolean

问题：

• 这种 （ab） 使用异常的技术是否有效？（它有名字吗？
• 如果有效，应该，或者是否就好了？（即使它的情况没有什么特别之处？FlyingPig extends ThrowableException