英文:
What is "JAVA exception handling mindset" in comparison with "C++ exception handling"?
问题
在https://isocpp.org/wiki/faq/exceptions中，它谈到了一些错误的异常处理心态，其中之一是所谓的“JAVA异常处理心态”，描述如下：
在Java中，非内存资源通过显式的try/finally块来回收。 当在C++中使用这种心态时，会导致大量不必要的try块，与RAII相比，这会使代码混乱不堪，并使逻辑变得更加难以理解。实质上，代码在“好路径”和“坏路径”之间来回切换（后者指的是在异常期间采用的路径）。通过RAII，代码主要是乐观的 - 全都是“好路径”，而清理代码则位于资源拥有对象的析构函数中。这还有助于降低代码审查和单元测试的成本，因为这些“资源拥有对象”可以在隔离状态下进行验证（使用显式的try/catch块，每个副本都必须进行单元测试和单独检查；它们无法作为一组处理）。
以下是我的问题：
-
为什么会**“在Java中，非内存资源通过显式的try/finally块来回收”，以及“当在C++中使用这种心态时，会导致大量不必要的try块”**？我不理解使用try/finally块来回收非内存资源是什么意思。
-
**“在隔离状态下进行验证”**是什么意思？（加粗部分：这些“资源拥有对象”可以在隔离状态下进行验证（使用显式try/catch块，必须对每个副本进行单元测试和单独检查；它们无法作为一组处理））
英文:
In https://isocpp.org/wiki/faq/exceptions, it talks about some wrong exception-handling mindsets, one of which is the "JAVA exception handling mindset", described as follows:
> In Java, non-memory resources are reclaimed via explicit try/finally blocks. When this mindset is used in C++, it results in a large number of unnecessary try blocks, which, compared with RAII, clutters the code and makes the logic harder to follow. Essentially the code swaps back and forth between the “good path” and the “bad path” (the latter meaning the path taken during an exception). With RAII, the code is mostly optimistic — it’s all the “good path,” and the cleanup code is buried in destructors of the resource-owning objects. This also helps reduce the cost of code reviews and unit-testing, since these “resource-owning objects” can be validated in isolation (with explicit try/catch blocks, each copy must be unit-tested and inspected individually; they cannot be handled as a group).
Here are my questions:
-
Why "In Java, non-memory resources are reclaimed via explicit try/finally blocks" and "When this mindset is used in C++, it results in a large number of unnecessary try blocks"? I do not understand what it means to use try/finally blocks to reclaim non-memory resources.
-
What does "validated in isolation" mean? (The bolded part: these “resource-owning objects” can be validated in isolation (with explicit try/catch blocks, each copy must be unit-tested and inspected individually; they cannot be handled as a group))
答案1
得分: 0
在C++中，我们可以使用RAII来进行所有资源管理。在Java中，我们使用GC来进行内存资源管理，并使用手动显式代码来进行非内存资源管理。
-
在Java中，要在异常情况下进行手动的非内存资源管理，我们必须使用显式的try/finally代码块。然而，在C++中进行相同操作会失去C++的全部优势。
-
它解释了单元测试资源拥有对象更简单，因为可以在隔离环境中完成，而显式管理的单元测试必须在进行显式管理的每个位置的上下文中完成。
英文:
In C++ we can use RAII for all resource management. In Java we have GC for memory resource management and manual explicit code for non-memory resource management.
-
To do that manual non-memory resource management on case of exceptions we have to use explicit try/finally blocks in Java. Doing same in C++ however loses the whole benefit of C++.
-
It explains that unit-testing resource owning objects is simpler as it can be done in isolation while unit testing of explicit management has to be done in context of each place where that explicit management is done.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论