问题标签 [try-finally]

查看Java 虚拟机规范和编译代码告诉我们如何在 java 中实现“同步”块。以下代码：

...大致相当于这个伪代码：

...除了一个例外。

出于某种原因，异常表显示了两个 finally 处理程序。例如：

第一个处理程序是我期望的，但第二个处理程序实际上是用于第一个处理程序的 finally 块，如果它捕获到异常，它会执行相同的处理程序。您可以通过以下方式将其可视化：

有人知道这是为什么吗？如果它只是 finally 块，则表中的第二个条目将不存在。此外，如果 finally 块已经抛出异常，我看不出有任何可能的原因要再次执行它。

谢谢，布兰登

我有一个简单的问题，一个简单的代码部分，一些基本try-finally块：

我的主要问题是：有什么方法可以发现是在finally块中抛出异常而不使用catch和一些局部变量在块之间传递信息？

我在少数情况下这很有用，我不想添加一些丑陋的不必要catch的块来设置一些变量throw Exception。第一个例子是，如果我在一些 Spring 或容器管理的事务方法中，并且发生了try阻塞Exception。在这种情况下，我需要创建新事务finally以使用数据库。第二个例子是我不想让我的原件Exception被Exception扔进finally块掩盖，但如果没有，Exception我会把它扔掉finally（如果有的话）。

我知道这一切都可以完成，catch但是还有其他方法吗，Java 中的一些元数据或其他任何方法？如果我们可以假设这将被一次性执行，那么它可能会有所帮助Thread，所以也许有一些方法可以发现 Exception bounded to current Thread？

由于这是一个关于 try/finally 子句行为的学术问题，因此我尝试使用一个非常通用的示例。像这样嵌套 try/finally 子句有什么危险吗？

具体来说，我很想知道是否closeCursor()保证在之前被调用closeDatabaseConnection()。是否有理由嵌套一个 finally 子句之类的应该被视为不好的做法？

我有一个简单的 Java 类，如下所示：

这段代码的输出是这样的：

为什么s没有在finally块中覆盖，而是控制打印输出？

我正在学习 Java（对不起，我的英语很差，这不是我的母语），当我在 Eclipse（JavaSE-1.7）中执行“try-finally”块时，在我输入的每个“尝试”中都会出现以下消息：

此行有多个标记 - 语法错误，插入“}”以完成 Block - 语法错误，插入“Finally”以完成 BlockStatements

这是完整的代码：

考虑 ：

如果 new InputStreamReader(file, charsetName)throws UnsupportedEncodingException，buffer.close();则永远不会调用该行。另一种方法是额外的冗长：

并且它不必要地关闭了所有流（虽然output.close();应该足够了 - 实际上，如果成功，它们中的任何一个都足够了 -请参阅 Skeet 代码中的注释）。

包装构造函数

本质上只是隐藏问题。

请注意，我在这里使用@TomHawtin-tackline 建议的 try-finally 习语- 但更常见的方法是：

一样尴尬。

问题 ：

你会如何处理这个案子？
将 ：

做 ？换句话说，当有超过 2 个包裹的流时，关闭最里面的流（与通常 要求的相反）将是最干净的解决方案？是否存在装饰器也应该关闭的情况？请参阅此处的示例点。请注意 Eclipse 警告：finally

资源泄漏：“缓冲区”永远不会关闭

日食是对的吗？

_{这是 Java 6 - 我提醒你，Android 只是 Java 6。尝试一劳永逸地在某些实用程序类中排除 IO 代码}

我在基于 Swing 的桌面应用程序中使用 JPA。这就是我的代码的样子：

我将它try - catch - finally用于所有需要事务的方法。它按预期工作，除了具有SwingUtilities.invokeLater().

finally将在新线程中的所有代码执行之前到达；因此，如果内部有 JPA 操作SwingUtilities.invokeLater()，则会因为事务已提交而失败。

是否有一个try - catch - finally我可以遵循的通用用例来确保只有在所有代码（包括内部代码）都已执行后才会提交事务SwingUtilities.invokeLater()？

我今天遇到了一个小问题，我有一段这样的代码，这让我有点不舒服......

我想知道这样的实现是否是一个好的实践，当异常发生时try并被重新抛出给处理它的调用者。这相当于下面的代码吗？

我有以下代码片段：

是否可以编写一个通用的辅助方法来抽象出模式？然后我可以使用这样的辅助方法：

当然下面的方法是行不通的，因为 Scala 不支持按引用传递：

我通过将step数据成员更改为隐式参数解决了这个问题。这样，我就不必恢复 的旧值step，因为它的值在同一范围内永远不会改变 :)

我正在处理的新模块中存在堆栈损坏问题，该模块是大型遗留项目的一部分。我的代码是使用 Borland C++Builder 5.0 用 C++ 编写的。

我已将问题跟踪到以下功能：

该函数在工作线程（从 TThread 派生）的上下文中调用。当数据可用时，另一个线程会用数据填充更改队列。更改队列受临界区对象保护。

运行代码时，我在尝试离开临界区时偶尔会遇到访问冲突。据我所知，有时当进入__finally部分时，堆栈已损坏。堆上的类实例很好，但指向类的指针（例如“this”指针）似乎无效。

如果我在更改队列为空的情况下删除返回调用，问题就会消失。此外，处理队列中项目的代码不是问题的根源，因为我可以将其注释掉，问题仍然存在。

所以我的问题是在 C++Builder 5 中使用__finally时是否存在已知问题？从try __finally块中调用return是否错误？如果是这样，为什么？

请注意，我意识到有不同/更好的方法来做我正在做的事情，我正在重构。但是，我不明白为什么这些代码会导致堆栈损坏。