{"id":3236,"date":"2011-01-25T11:51:00","date_gmt":"2011-01-25T11:51:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/subterranean-il-compiling-c-exception-handlers\/"},"modified":"2021-04-29T15:30:54","modified_gmt":"2021-04-29T15:30:54","slug":"subterranean-il-compiling-c-exception-handlers","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/subterranean-il-compiling-c-exception-handlers\/","title":{"rendered":"Subterranean IL: Compiling C# exception handlers"},"content":{"rendered":"

An exception handler in C# combines the IL catch<\/code> and finally<\/code> exception handling clauses into a single try<\/code> statement: <\/p>\n

try {\n    Console.WriteLine(\"Try block\")\n    \/\/ ...\n}\ncatch (IOException) {\n    Console.WriteLine(\"IOException catch\")\n    \/\/ ...\n}\ncatch (Exception e) {\n    Console.WriteLine(\"Exception catch\")\n    \/\/ ...\n}\nfinally {\n    Console.WriteLine(\"Finally block\")\n    \/\/ ...\n}<\/pre>\n
How does this get compiled into IL?<\/p>\n
Initial implementation<\/b><\/p>\n
 If you remember from my earlier post<\/a>, finally<\/code> clauses must be specified with their own .try<\/code> clause. So, for the initial implementation, we take the try\/catch\/finally, and simply split it up into two .try<\/code> clauses (I have to use label syntax for this): <\/p>\n
StartTry:\n    ldstr \"Try block\"\n    call void [mscorlib]System.Console::WriteLine(string)\n    \/\/ ...\n    leave.s End\nEndTry:\n\nStartIOECatch:\n    ldstr \"IOException catch\"\n    call void [mscorlib]System.Console::WriteLine(string)\n    \/\/ ...\n    leave.s End\nEndIOECatch:\n\nStartECatch:\n    ldstr \"Exception catch\"\n    call void [mscorlib]System.Console::WriteLine(string)\n    \/\/ ...\n    leave.s End\nEndECatch:\n\nStartFinally:\n    ldstr \"Finally block\"\n    call void [mscorlib]System.Console::WriteLine(string)\n    \/\/ ...\n    endfinally\nEndFinally:\n  \nEnd:\n   \/\/ ...\n   \n.try StartTry to EndTry\n    catch [mscorlib]System.IO.IOException\n        handler StartIOECatch to EndIOECatch\n    catch [mscorlib]System.Exception\n        handler StartECatch to EndECatch\n.try StartTry to EndTry\n    finally handler StartFinally to EndFinally<\/pre>\n<\/p>\n
However, the resulting program isn’t verifiable, and doesn’t run: <\/p>\n
[IL]: Error: Shared try has finally or fault handler.<\/pre>\n
Nested try blocks<\/b><\/p>\n
What’s with the verification error? Well, it’s a condition of IL verification that all exception handling regions (try<\/code>, catch<\/code>, filter<\/code>, finally<\/code>, fault<\/code>) of a single .try<\/code> clause have to be completely contained within any outer exception region, and they can’t overlap with any other exception handling clause. In other words, IL exception handling clauses must<\/em> to be representable in the scoped syntax, and in this example, we’re overlapping catch<\/code> and finally<\/code> clauses.<\/p>\n
Not only is this example not verifiable, it isn’t semantically correct. The finally<\/code> handler is specified round the .try<\/code>. What happens if you were able to run this code, and an exception was thrown? <\/p>\n
    \n
  1. Program execution enters top of try<\/code> block, and exception is thrown within it<\/li>\n
  2. CLR searches for an exception handler, finds catch<\/code><\/li>\n
  3. Because control flow is leaving .try<\/code>, finally<\/code> block is run<\/li>\n
  4. The catch<\/code> block is run<\/li>\n
  5. leave.s End<\/code> inside the catch handler branches to End<\/code> label.<\/li>\n<\/ol>\n
     We’re actually running the finally<\/code> before the catch<\/code>!<\/p>\n
    What we do about it<\/b><\/p>\n
    What we actually need to do is put the catch<\/code> clauses inside<\/em> the finally<\/code> clause, as this will ensure the finally<\/code> gets executed at the correct time (this time using scoped syntax): <\/p>\n
    .try {\n    .try {        \n        ldstr \"Try block\"\n        call void [mscorlib]System.Console::WriteLine(string)\n        \/\/ ...\n        leave.s End\n    }\n    catch [mscorlib]System.IO.IOException {\n        ldstr \"IOException catch\"\n        call void [mscorlib]System.Console::WriteLine(string)\n        \/\/ ...\n        leave.s End\n    }\n    catch [mscorlib]System.Exception {\n        ldstr \"Exception catch\"\n        call void [mscorlib]System.Console::WriteLine(string)\n        \/\/ ...\n        leave.s End\n    }\n}\nfinally {\n    ldstr \"Finally block\"\n    call void [mscorlib]System.Console::WriteLine(string)\n    \/\/ ...\n    endfinally\n}\n\nEnd:\n    ret<\/pre>\n
    Returning from methods<\/b><\/p>\n
    There is a further semantic mismatch that the C# compiler has to deal with; in C#, you are allowed to return<\/code> from within an exception handling block: <\/p>\n
    public int HandleMethod() {\n    try {\n        \/\/ ...\n        return 0;\n    }\n    catch (Exception) {\n        \/\/ ...\n        return -1;\n    }\n}<\/pre>\n<\/p>\n
    However, you can’t ret<\/code> inside an exception handling block in IL. So the C# compiler does a leave.s<\/code> to a ret<\/code> outside the exception handling area, loading\/storing any return value to a local variable along the way (as leave.s<\/code> clears the stack): <\/p>\n
    .method public instance int32 HandleMethod() {\n    .locals init ( int32 retVal )\n    \n    .try {\n        \/\/ ...\n        ldc.i4.0\n        stloc.0\n        leave.s End\n    }\n    catch [mscorlib]System.Exception {\n        \/\/ ...\n        ldc.i4.m1\n        stloc.0\n        leave.s End\n    }\n    \n  End:\n    ldloc.0\n    ret\n}<\/pre>\n
    Conclusion<\/b><\/p>\n
    As you can see, the C# compiler has quite a few hoops to jump through to translate C# code into semantically-correct IL, and hides the numerous conditions on IL exception handling blocks from the C# programmer.<\/p>\n
    Next time<\/a>: onto fault<\/code> handlers.<\/p>\n","protected":false},"excerpt":{"rendered":"
    An exception handler in C# combines the IL catch and finally exception handling clauses into a single try statement: try { Console.WriteLine(“Try block”) \/\/ … } catch (IOException) { Console.WriteLine(“IOException catch”) \/\/ … } catch (Exception e) { Console.WriteLine(“Exception catch”) \/\/ … } finally { Console.WriteLine(“Finally block”) \/\/ … } How does this get compiled……<\/p>\n","protected":false},"author":186659,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143538,2],"tags":[],"coauthors":[],"class_list":["post-3236","post","type-post","status-publish","format-standard","hentry","category-dotnet-development","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3236","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/186659"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=3236"}],"version-history":[{"count":3,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3236\/revisions"}],"predecessor-version":[{"id":75606,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3236\/revisions\/75606"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=3236"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=3236"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=3236"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=3236"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}