{"id":1104,"date":"2013-07-04T01:00:00","date_gmt":"2013-07-03T23:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1104"},"modified":"2013-08-12T11:41:20","modified_gmt":"2013-08-12T10:41:20","slug":"finally-no","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1104","title":{"rendered":"Finally, No"},"content":{"rendered":"

Why doesn\u00e2\u20ac\u2122t C++ have a finally<\/code> block? Here\u00e2\u20ac\u2122s some Java.<\/p>\n

void<\/span> userFunction<\/span>() {\n    f = new<\/span> Resource();\n    f.open<\/span>();\n    try<\/span> {\n        \/\/ might throw<\/span>\n        buffer = f.read<\/span>();\n    } finally<\/span> {\n        f.close<\/span>();\n    }\n    useBuffer<\/span>(buffer);\n}<\/code><\/pre>\n
It\u00e2\u20ac\u2122s tempting, after you\u00e2\u20ac\u2122ve had a finally<\/code> for a while to think that it\u00e2\u20ac\u2122s necessary for proper resource management in the face of exceptions. We\u00e2\u20ac\u2122ve not had to free up f<\/code> because Java\u00e2\u20ac\u2122s garbage collection will sort out the memory (although I\u00e2\u20ac\u2122m not a fan of that).<\/p>\n
You might see something like this in C++ to work around the lack of finally<\/code>:<\/p>\n
void<\/span> userFunction() {\n    Resource *f = new Resource;\n    try {\n        buffer = f->read();\n    } catch( ... ) {\n        f->close();\n        delete f;\n        throw;\n    }\n    useBuffer(buffer);\n}<\/code><\/pre>\n
Code like this is bad.<\/p>\n
Object oriented management of resources should be done by never using your resource in this, so-called, \u00e2\u20ac\u0153naked\u00e2\u20ac\u009d manner. To be fair it\u00e2\u20ac\u2122s not this code that\u00e2\u20ac\u2122s wrong, it\u00e2\u20ac\u2122s the code for Resource<\/code>, or possibly the code that hasn\u00e2\u20ac\u2122t been written to correctly manage a Resource<\/code>.<\/p>\n
The point of object oriented languages is to create new types, types that are intelligent. In particular, we should make use of the principle RAII, resource acquisition is initialisation<\/em>. By implication then, resource release is deinitialisation<\/em>.<\/p>\n
class unique_resource {\n  public:\n    unique_resource() {\n        resource = new Resource;\n        resource->open();\n    }\n    ~unique_resource() {\n        resource->close();\n        delete resource;\n    }\n    Resource &operator() { return<\/span> *resource; }\n  protected:\n    Resource *resource;\n};\n\n\/\/ ... elsewhere in the forest ...<\/span>\n\nvoid<\/span> userFunction() {\n    unique_resource f;\n    buffer = f().read();\n}<\/code><\/pre>\n
What matters here is no try..except<\/code> and no finally<\/code> in userFunction()<\/code>. They\u00e2\u20ac\u2122re all unnecessary because, should there be an exception, f<\/code> will be destructed automatically before the exception starts propagating back up the call stack.<\/p>\n
So, should you find yourself wishing C++ had a finally<\/code>, or for that matter, should you find yourself using<\/em> finally in Java<\/del>; you\u00e2\u20ac\u2122ve probably already done something wrong \u00e2\u20ac\u201c resources should be managed in an object, and they should manage themselves by virtue of the language features. You can\u00e2\u20ac\u2122t do this in Java, because of it\u00e2\u20ac\u2122s soft support for destructors (finalize()<\/code> is about the nearest, but that comes with caveats<\/a>).<\/p>\n
This principle applies even further; using new<\/code> outside of a constructor is indicative that you\u00e2\u20ac\u2122ve made a design mistake. In really simple cases C++11 can automatically supply you the object you should have written yourself with the unique_ptr<\/code> class.<\/p>\n","protected":false},"excerpt":{"rendered":"
Why doesn\u00e2\u20ac\u2122t C++ have a finally block? Here\u00e2\u20ac\u2122s some Java. void userFunction() { f = new Resource(); f.open(); try { \/\/ might throw buffer = f.read(); } finally { f.close(); } useBuffer(buffer); } It\u00e2\u20ac\u2122s tempting, after you\u00e2\u20ac\u2122ve had a finally for a while to think that it\u00e2\u20ac\u2122s necessary for proper resource management in the face\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[66,6],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1104"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1104"}],"version-history":[{"count":6,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1104\/revisions"}],"predecessor-version":[{"id":1200,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1104\/revisions\/1200"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}