Threading gotcha in C#

So, as I mentioned last time, Gnome Do rocks. So much in fact that I’m looking for ways to contribute to the project. I haven’t been this excited about a piece of software in quite some time. The nerd in me is giddy.

My first contribution was to fix a bug I opened against the JIRA Gnome Do plugin (an awesome plugin by the way). The bug was causing Gnome Do to crash at startup if the JIRA server could not be reached. The fix was pretty easy. Wrap the code throwing the exception that was causing the crash in a try/catch block, and simply log and swallow the exception. Gnome Do calls the plugin every 5 minutes to update its index, so once you eventually connected to the web or logged in to your company’s network and can see your JIRA server, the plugin will be able to index the JIRA issues and all will be peachy.

I tested the fix, and it worked like a champ. However, I started to think to myself that it was very odd that Gnome Do let a rogue plugin take it down. I figured it would be a good idea to isolate all calls to the plugins, and wrap them all in try/catch blocks, as a means to protect the core application. I did some digging in the code, and I found that Gnome Do was already doing exactly that. So why on earth did an exception in the plugin take down the core app?

I did some more digging, and in the JIRA plugin, the update takes place in a separate thread. The author of the JIRA plugin, knowing that the call from Do to update the plugin’s index was a blocking call, and knowing that the communication with JIRA may take a little while, decided to do the communication with JIRA in a different thread, and immediately return control to Do. It was this thread that was throwing the exception when the JIRA server could not be reached. This puzzled me. Could it be possible that an uncaught exception in a separate thread can take down the entire application? “No way in hell” I thought to myself.

I was wrong.

With Google by my side, I searched the web for “c# thread exception” and found this free e-book about threading in C#. At the very bottom of the page, read this:

From .NET 2.0 onwards, an unhandled exception on any thread shuts down the whole application, meaning ignoring the exception is generally not an option. Hence a try/catch block is required in every thread entry method at least in production applications in order to avoid unwanted application shutdown in case of an unhandled exception.

Holy crap! I showed this to a co-worker, who quickly whipped up a Java program that spawned a thread that threw an exception, to see what happened. We were pretty sure that only that thread would die, and that the JVM would continue to chug along as normal. Thankfully, we were right.

Why on earth would .NET behave this way? The e-book says “From .NET 2.0 onwards”, so I’m assuming that this wasn’t the case in .NET 1.0. I wonder what the reason was for this change. Now, any .NET application that allows itself to be extended by plugins is now at risk of being taken down, at any time, by a rogue plugin! Yikes!

I’m spoiled

Wow, I’m spoiled. Spending the past several years working with Java, Ruby, Erlang, and some others, I’ve grown accustomed to the hoards of free libraries and tools out there just begging to be used. IDEs, code analysis, continuous integration, frameworks, profiling, testing…pretty much anything you could ever want. This rings especially true for Java, since it has been in the limelight for so long. So, I was shocked to find out that there doesn’t appear to be a free comprehensive code coverage tool out there for .NET.

As I’ve mentioned before, I’m writing a test suite for Shotokan Karate of America‘s new membership administration system. The application is written in C#. The pace of development has picked up lately, and new code is being released for testing about every couple of weeks. I’m not too involved with the development of the application, so I don’t have much insight as to what has changed from release to release. So, I’ve been looking for a good code coverage tool to show me areas of the application’s code that I may be overlooking in my tests.

I wanted something like Cobertura for Java, which has a rich set of features, and a set of easy to read code coverage reports. But, the only thing I could find that even came close to Cobertura was NCover. Free? Nope. Try $149 a license. Oh…wait, you want the one with the HTML reports? That’s $299.

I’m new to .NET, so naturally this raises a bunch of questions. Is this the status quo in the .NET community? Is everything pay to play? How does this affect the community? If Joe Developer has a library that he thinks others might find useful, does he slap a price tag on it simply because that’s the way things are? How do free open source software projects in .NET (I’m assuming there are some) get started? Does this type of model encourage or discourage community involvement in a project?

Is it just me, or does anybody else think that it sucks to not have these tools freely available to the development community?

I should note that I am a giant tight wad. Don’t believe me? Ask my wife.