A little OO goes a long way

when you have some resource external to your program represented by some type (a file, a windows, a proxy to a variable in another machine), you'll *always* want to take steps to destroy a variable of this type. So, for each variable of this type, you'll be typing (and others will be reading, and it will inflation the SLOCcount of your code) "try \n ... finally \n ... ... \n end" for no good reason, and without adding to the intended semantics, and exposing yourself as the programmer to an error introduced by a typo, the forgetting of some condition, or even to the optimization of some condition that was impossible but suddently become possible (e. g., when you wrote the code you knew you were closing some file in every possible path but some maintenance creates a new code path, like some new exception coming from a new version of a library, where the file goes out of scope still open).

try {
  f = open(...)
  f.x()
  f.y()
  if( z ) f.writeCheckSumAndLastBuffer() else f.writeLastBuffer()
} finally {
  f.close()
}

{
   Resource someResource(...);
   resource.x();
   resource.y(); // throws
   resource.writeLastBuffer();
}

try (Resource r = new Resource(...)) {
  // Do something with r...
}

class LastBufferWriter {
public:
  LastBufferWriter(Resource resource): resource_(resource) {}
  ~LastBufferWriter() { resource_.writeLastBuffer(); }
private:
  Resource resource_;
};

... {
   Resource resource(...);
   LastBufferWriter writer(resource);
   // Anything below can throw or not throw, we don't care
   resource.x();
   resource.y();
}

Yes, I know. That's an inferior solution compared to destructors.

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