Slides Available for Effective .NET Framework based development: Exception handing and Memory Management

Wow – what a run!  I started in Dallas, then the Bay Area, then Houston, then Austin and ended the tour in Raleigh, NC.  They were all great events and I think I learned as much from the questions and conversations after as the folks that attended.  Thanks again for coming out.   But I do realize I missed most of the world in my little tour, so you can now download the slides!


CLR Exception and Memory Management
This downloadable presentation is an overview of best practices and issues with the usage of exceptions, and different issues surrounding memory management including the IDisposable pattern, finalizers, memorypressure, HandleCollector, and why the using statement (Using in VB) is your friend! It's an excellent overview of some fundamental exception and memory management topics.   


Remember, plagiarism is the highest forum of flattery… have fun!


Comments (11)

  1. Marlon Chen says:

    I attended your seminar in NC and raised a question about assertion. I don’t think my question was really clear. I would like to regroup my thoughts together, and hope you can help me again.

    I wanted to use assertions to let developers who use my classes know it is a code error, which they shouldn’t try to handle it, instead, they should fix their code.

    But I had problem when using unit test (NUnit in my case), which cannot catch assertions.

    In your seminar, you mentioned that in the next version of .NET framework, not only exceptions can be thrown, but also any object can, too. This design was driven by making .NET compatible with other languages, such as Throwable in Java.

    In Java, AssertionError is also a Throwable. Is assertion in .NET 2.0 similar to that, and can be caught? If it is, I am sure NUnit would soon make use of it. So that I can keep using assertion, and don’t have to work it around with throwing "FixYourCodeException" any more.

  2. Marlon Chen says:

    Me again. Another question about exception:

    Calling Thread.Abort() can throw an exception in another call stack. Following statement is quoted from MSDN library:

    "Calling this method usually terminates the thread."

    Is this guaranteed in .NET 2.0?

  3. Keith Hill says:

    Put me in the camp of "catch (Exception ex)" is more often than not – evil. What I don’t get is that these two statements on that same slide: "Don’t attempt to catch every exception a method could throw" and "Catch what you need to handle and let the rest pass" fly in the face of "catch (Exception ex)". With this catch expression you *will* catch every exception, even those that you *don’t* want to handle. Surely you’re not recommended casing on the type of the exception in the "catch (Exception ex)" statement?

  4. Joe Duffy says:


    We did make some changes to thread aborts in Whidbey, yes, but mostly to make it safer for code running in an aborted thread.

    For normal thread aborts, a ThreadAbortException gets raised at the point that the abort is received by the target thread. There’s an obvious race which determines what this point is, but it can be any arbitrary instruction. With a couple caveats: 1) we don’t respond to aborts while code is inside a finally block, and 2) we can’t respond to aborts if we’re in unmanaged code. In both cases, we process the request as soon as we exit either (assuming we’re not nested inside another instance of 1 or 2, of course).

    So the comment “usually terminates” is usually accurate. 😉

    There are ways to prevent an abort from happening altogether. For example, if the target thread were inside a try { } finally { while(true); } chunk of code, we would never be able to respond. Further, there are some known cases where we end up blocking in unmanaged code… this is very bad, as it means we can’t even respond to polite AppDomain unloads. For example, Socket.Accept is one such method. We can never respond to an abort until Accept unblocks, which in some cases will only happen after a new network request comes in (or the socket is closed explicitly)!

    It should be noted that async thread aborts are highly discouraged—that is, aborts initiated by a thread which is not the recipient of the abort. Synchronous aborts are fine because the htread calling Abort should know when it’s safe to do so. Async aborts are inherently dangerous. Even with the two caveats above, it’s unreasonable to think that any arbitrary piece of code would be willing or able to respond to an exception raised from any arbitrary instruction. This can lead to a crash at best and more likely corrupt data. We have an MDA in Whidbey that fires on this to help you find the root cause of such things.

    I hope this helps. Ciao.

Skip to main content