ATBG: How do exceptions interact with the “using” statement?

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.

Advertisements

7 thoughts on “ATBG: How do exceptions interact with the “using” statement?

  1. 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.”

  2. 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”.

  3. Pingback: Dew Drop – February 27, 2014 (#1732) | Morning Dew

  4. 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].

  5. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s