I just wanted to make sure you did not miss this article describing a mechanism to pause asynchronous processing. Just like the article state that this came out of a problem encountered in the UI World I think this is something I would not expect to see a lot outside the UI world. But it could be used for processing items in a work-flow at different priorities; i.e. pausing less important work in favor of more important work.
And when you're done reading about the PauseToken you should definitely read this one with some common problems people encounter.
It's been a while since I last looked at Rx and I must confess that my first impression was that the amount of possibilities to do the same thing and all the extension methods was overwhelming at start. But like with any new framework you learn you'll settle for a few to solve your most common problems after a while. But then I never saw a really compelling reason for using Rx and it has been very rare among my friends and colleagues to use Rx. So last week I was excited to read that Netflix uses it a lot and I'm looking forward to read more about how they uses and what they've learned along the way.
This was brought to my attention and I was blown away by the fact that somebody would mark classes as TestClass without any tests in them just to reuse some setup code. And that they then make any assumptions on in which order the methods are called. If you really want to do that the constructor is a great place for that and that is also why prefer xUnit.Net which does not have a TestInitialize through attributes but actually use the constructor instead. But I actually think it is better if you're more explicit about how you initialize your tests than relying on an order just defined by the order in which base classes are called by default. In general I believe the consensus is that composition is superior to inheritance when it comes to code reuse which is why you should not put yourself in a situation where you rely on execution order between base and child classes.
Recently I was asked about a specific scenario when some code was being converted into using TAP and this was code that already used tasks. Since the existing code used the "IsFaulted" property a lot I came up with this little extension method making it easy to see if a task failed or not using the await keyword but without adding a lot of exception handling.
1: public static Task<bool> WaitAsync(this Task task)
3: var tcs = new TaskCompletionSource<bool>();
5: t => tcs.TrySetResult(!(t.IsFaulted || t.IsCanceled)));
6: return tcs.Task;
So why avoid exceptions? Well I think that is a separate topic but a few short observations; exceptions have some performance penalties so you don't want to use them for common errors and some people think exceptions make it harder to follow the flow of the code. Whatever you think about all that I think you'll find the WaitAsync method useful more or less often.
Time for my 2012 according to this blog's statistics. As last year we'll start of with the five most read posts:
For the fourth year in a row native code coverage reports is the most read article I have on my blog. I was sad to see Object calisthenics not make top five. Another interesting thing though is that Ten commandments of egoless programming was linked by some popular sites which made it into the top. It in its turn links to the Viking laws which turned out to be much more popular than the commandments post. Exactly the way I feel. The top ten search terms to land on this blog in 2011 were (2010 ranking within parenthesis):