C# 5

(Just to be clear: I hate the word "explicitness". It reminds me of Rowan Atkinson as Marcus Browning MP, saying we should be purposelessnessless. But I can’t think of anything better here.) For the last few days, I’ve been thinking about context – in the context of C# 5’s proposed asynchronous functionality. Now many of the examples which have been presented have been around user interfaces, with the natural restriction of doing all UI operations on the UI thread. While that’s all very well, I’m more interested in server-side programming, which has a slightly different set of restrictions and emphases. … Continue reading The importance of context, and a question of explicitness

I’ve had a wonderful day with Mads Torgersen, and amongst other things, we discussed multiple exceptions and the way that the default awaiter for Task<T> handles an AggregateException by taking the first exception and discarding the rest. I now have a much clearer understanding of why this is the case, and also a workaround for the cases where you really want to avoid that truncation. Why truncate in the first place? (I’ll use the term "truncate" throughout this post to mean "when an AggregatedException with at least one nested exception is caught by EndAwait, throw the first nested exception instead". … Continue reading Multiple exceptions yet again… this time with a resolution

In an earlier post, I mentioned  that in the CTP, an asynchronous method will throw away anything other than the first exception in an AggregateException thrown by one of the tasks it’s waiting for. Reading the TAP documentation, it seems this is partly expected behaviour and partly not. TAP claims (in a section about how "await" is achieved by the compiler): It is possible for a Task to fault due to multiple exceptions, in which case only one of these exceptions will be propagated; however, the Task’s Exception property will return an AggregateException containing all of the errors. Unfortunately, that … Continue reading Propagating multiple async exceptions (or not)

One of the great things about working at Google is that almost all of my colleagues are smarter than me. True, they don’t generally know as much about C#, but they know about language design, and they sure as heck know about distributed/parallel/async computing. One of the great things about having occasional contact with the C# team is that when Mads Torgersen visits London later in the week, I can introduce him to these smart colleagues. So, I’ve been spreading the word about C# 5’s async support and generally encouraging folks to think about the current proposal so they can … Continue reading Configuring waiting

Yesterday I wrote about waiting for multiple tasks to complete. We had three asynchronous tasks running in parallel, fetching a user’s settings, reputation and recent activity. Broadly speaking, there were two approaches. First we could use TaskEx.WhenAll (which will almost certainly be folded into the Task class for release): var settingsTask = service.GetUserSettingsAsync(userId);  var reputationTask = service.GetReputationAsync(userId);  var activityTask = service.GetRecentActivityAsync(userId);  await TaskEx.WhenAll(settingsTask, reputationTask, activityTask);  UserSettings settings = settingsTask.Result;  int reputation = reputationTask.Result;  RecentActivity activity = activityTask.Result; Second we could just wait for each result in turn: var settingsTask = service.GetUserSettingsAsync(userId);   var reputationTask = service.GetReputationAsync(userId);   var activityTask = service.GetRecentActivityAsync(userId);          … Continue reading Dreaming of multiple tasks again… with occasional exceptions

Warning: as ever, this is only the result of reading the spec and experimentation. I may well have misinterpreted everything. Eric Lippert has said that he’ll blog about exceptions soon, but I wanted to put down my thoughts first, partly to see the difference between what I’ve worked out and what the real story is. So far, I’ve only covered "success" cases – where tasks complete without being cancelled or throwing exceptions. I’m leaving cancellation for another time, but let’s look at what happens when exceptions are thrown by async methods. What happens when an async method throws an exception? … Continue reading Control flow redux: exceptions in asynchronous code

I apologise in advance if this post ends up slightly rambly. Unlike the previous entries, this only partly deals with existing features. Instead, it considers how we might like to handle some situations, and where the language and type system thwarts us a little. Most of the code will be incomplete, as producing something realistic and complete is tricky. Almost everything I’ve written about so far has dealt with the situation where we just want to execute one asynchronous operation at a time. That’s the case which the await keyword makes particularly easy to work with. That’s certainly a useful … Continue reading Dreaming of multiple tasks

Some of you may remember the bizarre query expressions I’ve come up with before now. These rely on LINQ finding the members it needs (Select, Where, SelectMany etc) statically but without relying on any particular interface. I was pleased to see that the C# 5 async support is based on the same idea. Here’s the relevant bit of the draft spec: The expression t of an await-expression await t is called the task of the await expression. The task t is required to be awaitable, which means that all of the following must hold: (t).GetAwaiter() is a valid expression of … Continue reading C# 5 async: experimenting with member resolution (GetAwaiter, BeginAwait, EndAwait)