The Setup-Cleanup Problem

What I find an interesting design choice about Go’s approach (using ‘defer’) is that they are executed at the end of the function — not the end of the current block:<p><a href="https:&#x2F;&#x2F;play.golang.org&#x2F;p&#x2F;q5n0P-mKrmS" rel="nofollow">https:&#x2F;&#x2F;play.golang.org&#x2F;p&#x2F;q5n0P-mKrmS</a><p>This means that if you were to alter a function by placing parts of its body inside a loop, you may accidentally introduce O(n) buildup of deferred statements. This means that you could also be piling up resources associated with those resources (e.g., O(n) file handles).<p>Because the number of ‘defer’ calls is thus unbounded, it may be the case the compiler needs to generate code to store the list of pending closures on the heap. This may already happen for bounded functions if the compiler is unable to analyze it. In those cases it may thus be faster to resort to traditional C-like error handling.<p>Optimizer passes for eliminating this overhead were added to Go 1.13: <a href="https:&#x2F;&#x2F;golang.org&#x2F;doc&#x2F;go1.13#runtime" rel="nofollow">https:&#x2F;&#x2F;golang.org&#x2F;doc&#x2F;go1.13#runtime</a>

When mentioning C# (not sure about any other language), I would have mentioned the using statement and IDesposable objects.<p>This way each object&#x27;s needed cleanup is encapsulated in each objects dispose method(s).<p>Granted using compiles down to a try-catch-finally with the Dispose method called in the finally, but there is an elegance to it.<p><a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;csharp&#x2F;language-reference&#x2F;keywords&#x2F;using-statement" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;csharp&#x2F;language-refe...</a>

A comparison like this would be much more informative if it used more than one layer of setup&#x2F;cleanup. When you get to four or five, it really highlights how well some of these scale up (or not). Also, neither nested functions nor mini state machines seem to get a mention, which is a shame. Nested functions are a good example of an approach that gets unwieldy fast as layers are added, and mini state machines scale as well as the &quot;kernel&quot; style without having to endure app-snobs&#x27; sneers for using a lowly goto.

The C# version is lacking the using pattern. <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;csharp&#x2F;language-reference&#x2F;keywords&#x2F;using-statement" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;csharp&#x2F;language-refe...</a>

Another very interesting take on this from Andrei Alexandrescu:<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;WjTrfoiB0MQ" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;WjTrfoiB0MQ</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;CppCon&#x2F;CppCon2015&#x2F;blob&#x2F;master&#x2F;Presentations&#x2F;Declarative%20Control%20Flow&#x2F;Declarative%20Control%20Flow%20-%20Andrei%20Alexandrescu%20-%20CppCon%202015.pdf" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;CppCon&#x2F;CppCon2015&#x2F;blob&#x2F;master&#x2F;Presentatio...</a>

Since Java 7, try with resources handles this in a much cleaner way than the example.<p><a href="https:&#x2F;&#x2F;docs.oracle.com&#x2F;javase&#x2F;tutorial&#x2F;essential&#x2F;exceptions&#x2F;tryResourceClose.html" rel="nofollow">https:&#x2F;&#x2F;docs.oracle.com&#x2F;javase&#x2F;tutorial&#x2F;essential&#x2F;exceptions...</a>

It&#x27;s weird to include a testing framework in it.<p>That just speaks to usage of any orchestration class with overridable hooks, and has everything to do with events pertaining to domain (xunit&#x27;s domain being &quot;run a series of isolated tests&quot;) and not clarifying lower-level code organization. It&#x27;s sort of like the author treated onFocus and onBlur in JS DOM events as startup&#x2F;cleanup. It&#x27;s just entry&#x2F;exit orchestration.<p>The editorial stuff about being unnecessary also ignores that unit tests must fully reset the fixture between every test to be isolated--one reason test doubles are nice, they can generally be reset instantly--and that one of the more popular ways to organize unit tests is around common fixture handlers, aka setup&#x2F;teardown routines.<p>This usually makes sense if you&#x27;re testing units of an otherwise cohesive module since related operations usually use related fixtures. If it doesn&#x27;t make sense then, sure, you move the setup&#x2F;cleanup into each test but it totally craps up being able to review them for validity, etc.<p>Ideally a test is a clean known fixture handed to the test, one state change, and a verification of post-state, nothing more. Anything else complicates the test to some extent or the other, and (though devs get this wrong constantly) readability is paramount in tests or you don&#x27;t know you&#x27;re testing the right thing six months from now. Tests have to be their own docs. That&#x27;s why setup and teardown exists, to hold everything but that.<p>Most of the article was pretty good, though.<p>Just...ruby, python, C++, xunit...misguided testing advice...wtf? Felt like the author was swimming outside their lane and missed a pass in editing, frankly.

There&#x27;s also linear types, where you only give things capable of closing a resource a type that consumes a linear type.<p>There&#x27;s also monadic resources, which you can view as a combination of RAII and what the author calls higher order functions.<p>Finally there&#x27;s also monadic regions (as distinct from resources), which take advantage of higher rank types.

There&#x27;s also Haskell&#x27;s &quot;bracket&quot; (<a href="https:&#x2F;&#x2F;wiki.haskell.org&#x2F;Bracket_pattern" rel="nofollow">https:&#x2F;&#x2F;wiki.haskell.org&#x2F;Bracket_pattern</a>) which is similar to python&#x27;s &quot;with&quot; statement but with plain functions instead of context managers.

Rusts Drop trait is a really elegant one missing from the article.

You can do the Go style defer using boost&#x27;s scope exit. It&#x27;s also in wil if you use windows.