问题标签 [throwable]

Effective Java (Second Edition)的第 4 条讨论了使用私有构造函数来强制执行不可实例化。这是书中的代码示例：

然而，AssertionError这似乎不是正确的扔东西。没有任何东西被“断言”，这就是 API 定义AssertionError使用的方式。

Throwable在这种情况下通常有什么不同吗？一个人通常只是抛出一个Exception带有信息的将军吗？或者为此编写一个习惯是否很常见Exception？

这很简单，但我想我只是从风格和标准的角度对它感到好奇。

给定：Throwable是Exception的超类。

当我阅读有关编写自己的“例外”的文本时，我看到了Throwable在catch块中使用的示例，而其他文本显示new Exception() 在catch块中使用。我还没有看到关于何时应该使用每个的解释。

我的问题是，什么时候应该Throwable使用，什么时候应该new Exception()使用？

在catchorelse块内使用：

或者

多年来一直在做 Java，所以一直没有跟踪 C++。语言定义中的 C++ 异常处理中是否添加了finally子句？

是否有模仿 Java 的 try/finally 的流行习语？

我还担心 C++ 没有针对所有可能抛出的异常的终极超类型——比如 Java 的 Throwable 类。

我可以写：

附录编辑：

我最终接受了投票最多的答案，即使用析构函数进行清理。当然，从我自己的评论来看，很明显我并不完全同意这一点。然而，C++ 就是这样，所以在我想到的应用程序努力中，我将或多或少地努力坚持共同的社区实践。我将使用模板类来包装还没有类析构函数的资源（即 C 库资源），从而赋予它们析构函数语义。

新附录编辑：

嗯，而不是finally然后是一个关闭功能？结合 ScopeGuard 方法的闭包（请参阅下面的答案之一）将是一种通过任意操作完成清理并访问清理代码的外部范围上下文的方法。清理可以以 Ruby 编程中的惯用方式完成，在打开资源时它们提供清理块。是否没有考虑 C++ 的闭包功能？

我正在尝试了解有关基本 Java 和不同类型的 Throwables 的更多信息，有人可以让我知道异常和错误之间的区别吗？

有时，您只需要捕获 Throwable，例如，在编写调度通用项目并需要从任何错误中恢复的调度程序队列时（所述调度程序记录所有捕获的异常，但静默，然后在其他项目上继续执行）。

我能想到的一个最佳实践是，如果异常是 InterruptedException，则总是重新抛出异常，因为这意味着有人打断了我的线程并想要杀死它。

另一个建议（来自评论，而不是答案）是总是重新抛出ThreadDeath

还有其他最佳实践吗？

我认为 Exception.fillInStackTrace 应该返回 Exception 或派生的 Exception 对象。考虑以下两个函数，

1. 在第一个函数中exception handler无法捕捉到。new Throwable()f()
2. 可以在第二个函数中exception handler捕获。e.fillInstackTrace()g()
3. 但是第二个功能g()仍然需要throws Throwable. 这真的很奇怪，因为我们可以捕捉到e.fillInstackTrace().

所以我的问题是为什么 Exception.fillInStackTrace 不返回 Exception 或 Exception-derived 而不是开发这种奇怪的语法？

编辑：澄清我的问题：我所说的“奇怪的语法”是什么
意思

1. 由于Exception.fillInStackTrace()返回Throwable引用，接收Exception引用的异常处理程序不应该能够捕获异常。因为java不允许隐式向下转换，它应该是类似的return (Exception)e.fillInstackTrace()。
2. 由于设计为接收Exception引用的异常处理程序可以处理Throwable异常，因此无需标记方法g()抛出Throwable异常。但是java编译器会强制我们这样做。

谢谢。

我知道

有相当大的开销，因为它创建了一个完整的堆栈跟踪等
。

提出同样的问题？这种行为是继承的，还是抛出 Throwable 的开销较小（o 否）？

编辑
从分析师的角度来看，输入错误密码的用户是程序正常执行顺序的例外。所以如果我有：

从分析师的角度来看，抛出 UserNotValidException 听起来是正确的。
如果您的代码具有非常好的抽象，则返回null或0只是听起来不正确。我只是想知道我是否可以在代码中真正实现这一点，或者我是否不得不将其留给理论。

编程观点异常和分析师观点异常之间有很大的区别。

注意：我给出了一个非常简单和愚蠢的例子，这不是我的情况。
注2：我知道返回null是很平常的事情，但是我需要有适当的抽象和OO代码，而且，就我个人而言，我认为这没有什么坏处。

API 文档说永远不要捕获表示异常行为的Throwable子类错误。这是否意味着 Error 和 Exception 之间的分离是为了告诉程序员应该捕获哪个子类，不应该捕获哪个子类？或者还有更多？

有时，我看到

而有时

有什么区别？

为什么Java不支持泛型Throwable？

我意识到类型擦除会使某些事情复杂化，但显然 Java 已经做了很多事情，所以为什么不把它再推一个档次并允许泛型Throwable，对潜在问题进行全面的编译时检查呢？

我觉得类型擦除参数相当弱。目前，我们不能这样做：

当然，没有它我们也能过得去。我不是要求我们应该能够在同一个块中做catch Bouncy<T1>，但是如果我们在具有严格编译时可执行规则的不相交的上下文中使用它们（这几乎是泛型现在的工作方式），不是吗？可行吗？Bouncy<T2>try