Today on the Coverity Development Testing Blog‘s continuing series Ask The Bug Guys, I answer a question I get quite frequently: what guarantees do we have about object disposal when the body of a using block is interrupted by an exception? The situation is rather complicated, it turns out.
As always, if you have questions about a bug you’ve found in a C, C++, C# or Java program that you think would make a good episode of ATBG, please send your question along with a small reproducer of the problem to TheBugGuys@Coverity.com. We cannot promise to answer every question or solve every problem, but we’ll take a selection of the best questions that we can answer and address them on the dev testing blog every couple of weeks.
Fabulous adventures in coding 
I do enjoy these “not so fast, bub” technical corner-cases. By and large, the rule of thumb to live by here is “most of the time, don’t worry; you’ll never encounter this.” And the flip side is “if you encounter this, you really, really, really need to worry about it and do it right.”
Interesting article. I noticed that you broke two of your own taboos in it- calling finalizers “destructors” and referring to an object being allocated on the heap (an implementation detail) rather than saying it was allocated on the “long term memory store”.
The C# specification calls finalizers “destructors”. It is unfortunate that we have two terms for the same thing; I use them interchangably which is maybe a bad habit.
Pingback: Dew Drop – February 27, 2014 (#1732) | Morning Dew
Would it be possible for C# to implement a `using` block in such a fashion that, given a `new` expression of a type which was tagged (via attribute) as supporting disposal of partially-constructed instances, it could move the creation of the temporary object into the `try` block, or would the Verifier balk at such code [I’m pretty certain the JVM verifier would balk, but .NET has different rules].
What’s the deal with thread abort exception anyway?
I mean, why does CLR even tries to run user-specific clean-ups in case of thread abortion? There is always a point of time when clean-up is already needed, but this fact isn’t recorded; so either you call native TerminateThread, or managed Thread.Abort you still have to be aware that you leak resources, including acquired locks (which are not released) — so pretty much after a thred was nuked, the process behaviour is undefined.
But why would you want to abort a thread anyway? Show a user a sad message, save what can be saved, and terminate the whole process.
I expect it comes down to doing the best you can, even when the chips are down.
The app presumably can’t be saved, but at least some of the time you won’t have to restart you RDBMS as well, or stuff like that.
I suppose these kind of considerations are to change “some” into “most”, recognising that “all” is pretty much impossible.
All links to the actual blog post seems broken. They takes to Synopsis blog corner. Would that be fixable else this would be a link only blog with very minimal value