What is "JAVA exception handling mindset" in comparison with "C++ exception handling"?

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:

1. 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.

2. 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))

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.

1. 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++.

2. 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.