{"id":25,"date":"2004-08-13T12:29:42","date_gmt":"2004-08-13T17:29:42","guid":{"rendered":"http:\/\/stein.everybody.org\/journal\/exceptions-in-the-finally-block\/"},"modified":"2004-08-13T12:29:42","modified_gmt":"2004-08-13T17:29:42","slug":"exceptions-in-the-finally-block","status":"publish","type":"post","link":"https:\/\/jeremystein.com\/journal\/exceptions-in-the-finally-block\/","title":{"rendered":"Exceptions in the finally block"},"content":{"rendered":"<p><em>My apologies to non-programmers.  Today, I have something to say about exceptions that are thrown in the finally block&#8230;<\/em><\/p>\n<pre>conn = new Connection(...);\ntry {\n    \/\/ database operations\n} finally {\n    conn.close();\n}<\/pre>\n<p>Now, suppose some database operation in the try block throws an exception.  Before that exception is propogated to the caller, the finally block is executed.  In my experience, it&#8217;s common for a failed database operation to prevent the connection from closing normally.  Thus, conn.close() itself throws an exception.  Which exception is received by the caller?  The original exception or the close exception?  Unfortunately, the close exception is propogated, masking the original exception (the only one we really care about).<\/p>\n<p>So, here&#8217;s what I&#8217;ve often done in the past:<\/p>\n<pre>conn = new Connection(...);\ntry {\n    \/\/ database operations\n} finally {\n    try {\n        conn.close();\n    } catch (Throwable t) {\n        \/\/ Ignore it to avoid masking original exception\n    }\n}<\/pre>\n<p>And that has worked fairly well for me.  However, in a recent project, we noticed that we were receiving an error closing a connection.  The code was similar to the first example above, so I changed it to be like the second example, so that we could see the original exception.  The result?  No exception was thrown.<\/p>\n<p>Uh-oh.  So, in the case when nothing else goes wrong, but the connection can&#8217;t be closed, I&#8217;ve completely hidden that failure.  What should I do?<\/p>\n<p><strong>Option 1:  Write complicated code<\/strong><\/p>\n<pre>conn = new Connection(...);\nThrowable finallyProblem = null;\ntry {\n    \/\/ database operations\n} finally {\n    try {\n        conn.close();\n    } catch (Throwable t) {\n        finallyProblem = t;\n    }\n}\nif (finallyProblem != null) {\n    throw finallyProblem;\n}<\/pre>\n<p>Yeah, that&#8217;s a bit excessive.<\/p>\n<p><strong>Option 2:  Log it<\/strong><\/p>\n<pre>conn = new Connection(...);\ntry {\n    \/\/ database operations\n} finally {\n    try {\n        conn.close();\n    } catch (Throwable t) {\n        log.warning(t);\n    }\n}<\/pre>\n<p>Yeah, I guess that works.  But how often do you check your logs?<br \/>\n<strong><br \/>\nOption 3:  Rationalize away the problem.<\/strong><\/p>\n<p>This is my favorite option &lt;grin&gt;.  Stick with the code that discards the exception in the finally block.  Theoretically, code that releases resources should not throw an exception.  Ever.  It makes it very difficult (impossible?) to create <a href=\"http:\/\/www.octopull.demon.co.uk\/java\/MoreExceptionalJava.html\">exception-safe<\/a> code if you can&#8217;t make that assumption.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>My apologies to non-programmers. Today, I have something to say about exceptions that are thrown in the finally block&#8230; conn = new Connection(&#8230;); try { \/\/ database operations } finally { conn.close(); } Now, suppose some database operation in the try block throws an exception. Before that exception is propogated to the caller, the finally [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-25","post","type-post","status-publish","format-standard","hentry","category-geek"],"_links":{"self":[{"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/posts\/25","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/comments?post=25"}],"version-history":[{"count":0,"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/posts\/25\/revisions"}],"wp:attachment":[{"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/media?parent=25"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/categories?post=25"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jeremystein.com\/journal\/wp-json\/wp\/v2\/tags?post=25"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}