The traditional pattern for writing events in C# has been a 3 step process:

1. Define the event in your class.
2. Define a utility function to check if the event isn’t null, then fire it.
3. Write code that calls the utility function.

An example:

public event Action<object,EventArgs> MyEvent;

protected virtual void OnAction(object sender, EventArgs args)
{
  if(MyEvent != null)
  MyEvent(sender, args);
}

...

//somewhere late in code
OnAction(this, new EventArgs);

This pattern, or variants of it, can be found all over the .Net framework, in various component suites, and in many .Net applications.  I have used it for years.  But with the advent of .Net 3.5′s abbreviated “lambda” style for delegate construction, a new pattern has emerged.  It took a while for me to convince myself that it is better, but I now use it all of the time.  This is also a three step process:

1. Define the event in your class.
2. Write an anonymous delegate for the event in the class constructor.
3. Write code that directly fires the event.

An example:

public event Action<object,EventArgs> MyEvent;

public MyClass()
{
  //an anonymous delegate that does nothing
  MyEvent += (sender, e) => {};
}

...

//somewhere late in code
OnAction(this, new EventArgs);

Of course this could also be done in .Net 2.0 using the old anonymous delegate syntax, and since it all runs on the same CLR, its prolly the exact same IL.

The vital difference in these two patterns is the checking for a null value of the event. In the first pattern, a conditional statement is checking to make sure that the event is not null i.e. something is subscribed to the event. The second pattern doesn’t have to check this because we subscribed to the event in the constructor.  The event will never be null. What are the pros of doing it the second way?

1. No conditional code needs to be written.  This eliminates bugs.
2. Repetitive code is eliminated.
3. The code is easier to follow.  Events are fired directly instead of going through a utility function.
4. The code is easier to maintain, since there is less code.
5. This is a rather anal point, but this code is also more thread safe.  In the first pattern an event could theoretically have a subscriber when checked, and not have one by the time it is called.  Like I said, pretty anal but true.

Of course the con here is creating a delegate for an event that may never be fired.  Delegates take up some small amount of ram, yada yada yada.  The OO prgrammer in me didn’t like the smell of this solution.  The pragmatist in me won out.  It is easily worth the trade-off in the small amount of resources needed for the anonymous delegates in the 2nd pattern to eliminate all of the cons of the first pattern.

I first started programming .Net in 2000.  I got my hands on the Beta 2 version of .Net 1.0.  In those days I was programming in VB6, so VB.Net seemed like the best choice.  But a couple of weeks after downloading the beta I was in a book store and saw a C# book.  I picked it up and started thumbing through it.  I remember I said something out loud like, “Wow, this is just like Java!” I had programmed in Java for a while as well, and had a background in C/C++. I preferred the syntax greatly to that of VB.  From there on out I tried to do all my .Net stuff in C#.

I recount this tale because I so rarely find something in C# I don’t know or understand. This is bragging. Its just the reality of getting to know a language/environment over several years. 

Of course there are new language features released every year or two that I have to work to learn.  But all in all, the language isn’t much of a mystery to me.  So yesterday when a coworker told me I was using a throw statement in a catch clause wrong, I was very surprised.  I was doing something like:

try
{
  ...
  SomethingThatMyThrowEx();
}
catch(Exception ex)
{
  ...
  throw ex;
}

So what is wrong with this? I didn’t see anything wrong at all. I wanted to catch the exception, take some action, and simply re-throw the exception. And this code will do that. The problem is, the exception will have a new stack trace from the point at which I re-throw it. Why? Because the throw statement takes and expression, not an object. The “ex” object in this case is being used as an expression of how the exception should look when thrown. This seems really strange, but it is in the C# language spec. Crap, how did I miss this all these years!

When C#/.Net executes the throw line it uses the exception object as an expression of how the expression should be thrown, and ads a stack trace from the current location in code. The previous stack trace is gone.

So how do we preserve the stack trace? We use only the throw keyword with no expression. This instructs .Net to simply continue the exception bubble-up process:

try
{
  ...
  SomethingThatMyThrowEx();
}
catch(Exception ex)
{
  ...
  throw; //no ex
}

Pretty simple, and pretty damn subtle. I won’t forget that one!

Microsoft is currently developing a new set of additions to .Net called the Parallel FX Library.  The library is intended to provide a better/easier API for multi-threading in .Net.  Anyone familiar with .Net will tell you that it already provides a rich threading library.  It is fairly easy to create and use threads in .Net using a number of approaches.  When I first read about the Parallel FX Library months ago, I was completely unexcited.  Last week I finally decided to take a look at the technology, and now I am excited.

Microsoft new libraries for threading is a giant leap forward for parallel tasks.  It is not a replacement for traditional, long running threads.  Instead, it is intended to help the developer offload tasks to multiple threads for performance gains on mult-core systems.  You cannot walk into a computer store and buy a new computer that isn’t at least dual core, so it makes sense that Microsoft would be targetting these platforms.

So far I have only explored the two areas of the Parallel FX Library, the basic Tasks framework, and the psuedo-looping mechanisms.

The Task is the basic unit of multi-threadedness in PFX.  The task encapsulates a delegate that will run on a thread.  The class Task is contained within the new namespace System.Threading.Tasks.

int x = 0;

//creates task, schedules for execution
Task task = Task.Create(foo => { x += (int)foo; }, 2);

//wait until execution is complete
task.Wait();

Console.WriteLine(x); //2

This example is very simple but illustrates the core concept that is the Task class.  As soon as Task.Create() returned the anonymous delegate was scheduled, and probably executing on a background thread.  The call thread.Wait() simply made the main thread hold until the value returned.  For those with a threading background, the Wait() statement will be obvious.

So what did this buy us?  Well, not a whole heck of a lot.  But this is just a very simple example.  Microsoft has built a lot of cool functionality on top of Task that will allow you to spawn all kinds of threads without having to manage them, all based on Task.

Consider the following example, which would not make very good production code but hopefully makes good example code:

int x = 0;
List<Task> tasks = new List<Task>();

//creates task, schedules for execution
for (int i = 0; i < 100000; i++)
{
Task task = Task.Create(foo => { x += (int)foo; }, i);
tasks.Add(task);
}

foreach (Task task in tasks)
task.Wait();

Console.WriteLine(x);

This code should run faster than a straight loop doing the same thing because these computations will be distributed to multiple threads which hopefully will be executed on multiple processor cores.  This code works, but I am still having to keep track of the tasks.  It seems like this should be done for me, and after a little digging I found that Microsoft has a class called Parallel in System.Threading.  This class has a few, very convenient static functions, For, For<>, and ForEach<>.  As you might guess, these functions act like loops.

int x = 0;
Parallel.For(0, 100000, foo => { x += foo; });
Console.WriteLine(x);

As you might guess, Parallel.For() is utilizing the Task class under the covers to execute the included anonymous delegate (lambda) to accomplish the same result as I wrote above.  The function signature for For takes an Action<int>, so we don’t need to cast foo to int.  The call does not return until all of the execution is completed.

Pretty cool so far.  We are now able to do repetitive operations on multiple threads with minimal code and no thread management.  For<> simply adds a generic type declaration for Action<>, and ForEach<> allows enumeration across a set of objects for the work.

I plan on digging into PFX more over the next week or two.  Some thought that this library might be release with .Net 3.5 SP1.  I would imagine that there will be another .Net release like .Net 3.6 or .Net 4.0 that will include PFX plus other works in progress like ASP.Net MVC.

I am a little tired of using the SQL like syntax that is available for LINQ.  Don’t get me wrong, LINQ and the language / .Net features introduced to support it in .Net 3.5 are great.  I don’t find myself using the SQL to LINQ at all, but I constantly find myself using LINQ with collecitons and XML.  After almost a year with the enhancements (in beta version this in GA .Net 3.5), the appeal of the SQL-like syntax has worn off, and I have come to realize that I enjoy using the actual function calls to which this psuedo-SQL-language is mapped.

I think the the SQL-like LINQ syntax was just the sugar to attract attention to LINQ.  In practice I have found that it make my code less readable.  To a developer that is not intimately familiar with LINQ, a complex expression is completely unintuitive.  It is just enough unlike SQL to confuse.  When it comes to complex select statements, joins, and other operations that are outside the standard SELECT…FROM…WHERE syntax (or FROM…WHERE…SELECT in LINQ), simply calling the framework functions directly makes more sense to me.  It creates code that is easier for C# developers to read.  It isn’t pretending to be SQL, and so it becomes much easier to follow what is really happening to anyone that understands enumeration, iteration and delegates.  With function chaining, it is also easy to write very clean chunks of code by use of indentation.  And when I have to explain the code to another developer that is unfamiliar with LINQ I can simply say, “.Select() is run for each record, .OrderBy() is run on the collection to sort the records, etc”.  With the SQL syntax I first must explain the mappings.

I have found myself rewriting old SQL syntax to C#/LINQ when I need to add new functionality.  As much as I use LINQ, I still have to look-up how to do certain operations when using the SQL-like syntax, but find it easy to write the same functional code with pure C#/LINQ extension calls.

I admire what the Microsoft .Net team did with LINQ, but I think I will be skipping the SQL syntax from now on.

Mix is Microsoft’s conference on various web-centric technologies such as ASP.Net, AJAX and Silverlight. It is taking place March 5 – 7 in Las Vegas. MS just extended the deadline for the discounted registration until the end of January. I just signed up this weekend for the conference and am really looking forward to the event. I am particularly excited to see Silverlight 2.0. Microsoft will either be releasing GA code, or a late beta for Silverlight 2.0 at the conference, depending on who you believe. I encourage anyone that can get reservations to attend.