\nConsider the following code,\nwritten in C# just for kicks; the problem is generic to any\nenvironment that supports exception handling.\n<\/p>\n
\nvoid ObliterateDocument()\n{\n try {\n try {\n document.DestroyAll();\n } finally {\n document.Close();\n document.DestroyExtensions();\n document.DestroyPlugins();\n }\n } finally {\n document.Destroy();\n }\n}\n<\/pre>\n\nSome time later, you find yourself facing an assertion\nfailure from document.Destroy()<\/code> claiming that you are\ndestroying the document while there are still active plugins.\nBut there is your call to document.DestroyPlugins()<\/code>,\nand it’s in a finally<\/code> block, and the whole point\nof a finally<\/code> block is that there is no way you can\nescape without executing it.\n<\/p>\n\nSo why didn’t document.DestroyPlugins()<\/code> execute?\n<\/p>\n\nBecause your exception handler itself encountered an exception.\n<\/p>\n
\nThe exception handler is not active during its own\nfinally<\/code> clause.\nAs a result,\nif an exception is thrown during document.Close()<\/code>,\nthe exception handler search begins at the block\noutside<\/strong> the finally<\/code> block.\n<\/p>\n\n(That the exception handler is not active during its own\nfinally<\/code> clause should be obvious. It would mean\nthat if an exception were to occur during the finally<\/code>\nclause, the program would go into an infinite loop. And it also\nwouldn’t be possible to rethrow a caught exception; your throw<\/code>\nwould end up caught by yourself!)\n<\/p>\n