A little OO goes a long way

try..finally is a very poor alternative. Running the destructor when the object goes out of scope or is deleted gives you strict, deterministic cleanup. Using try..finally means I have to reimplement the same logic, *by hand*, everywhere in the codebase where the object goes out of scope. And if I forget to do this in just one place, I'm now leaking resources. What's the chance that this will happen in a codebase of any appreciable size, especially allowing for changes as a result of ongoing maintenance and refactoring? It is effectively guaranteed.

The really great thing about this being done in the destructor is that I can be satisfied that I will never leak resources by default, ever. It's simply not possible. This is the real beauty of RAII; cleanup just happens under all circumstances, including unwinding by exceptions.

As a relatively recent newcomer to Java from a C++ background, I have to say I find the resource management awful, and this stems directly from its lack of deterministic destruction. While it might do a decent job of managing memory, every other resource requires great care to manage by hand, be it file handles, locks or whatever, and I've seen several serious incidents as a result, typically running out of file handles. And the enforcement of checking all thrown exceptions itself introduces many bugs--you can't just let it cleanly and automatically unwind the stack, thereby defeating one of the primary purposes of having exceptions in the first place--decoupling the throwing and handling of errors.

By way of comparison, I haven't had a single resource leak in the C++ program I maintain in 8 years, through effective use of RAII for all resources (memory, filehandles, locks).

Regards,
Roger