Nullable types (basics)

You have most likely come across such code:

int? i = 5;

By using “int?”, the integer which usually is a value type, becomes a nullable type. More specifically variable “i” is an instance of System.Nullable<T>. It can hold all values of an integer plus the null value. Nevertheless it behaves more or less like an integer. A nullable type can hold the value null, but not be itself null. Therefore you can still use the variable “i” even though you assign null to it.
Nullable types are very useful when using databases. Database booleans may not be initialized. The System.Nullable<bool> can replicate that properly by allowing 3 values: true, false and null.

static void Main(string[] args) {
    int? i = 5;

    Console.WriteLine(i.ToString());
    i = null;  // important: we assign a null value, we do not assign null to the variable
    Console.WriteLine("null value ToString(): " + i.ToString());  // the variable itself is not null, no exception
    Console.WriteLine("no exception thrown!");

    //string s = null;
    //Console.WriteLine(s.ToString());  // throws a NullReferenceException as expected

    Console.WriteLine(i.HasValue ? "variable i has a value" : "variable i has no value");
    i = 7;
    Console.WriteLine(i.HasValue ? "value of variable i is " + i : "variable i has no value");
    i = null;
    Console.WriteLine("default value is: " + i.GetValueOrDefault()); // i.GetValueOrDefault() returns a value type (=integer)
    //Console.WriteLine("the integer value is: " + i.Value); // throws an exception, null cannot be unboxed

    i = 1;
    int b = 2;
    Console.WriteLine(b + i + 3);  // no problem using operators
    Console.WriteLine(i.Value);

    Console.ReadLine();
} //

example output:
5
null value ToString():
no exception thrown!
variable i has no value
value of variable i is 7
default value is: 0
6

A nullable type can only be created for value types. Reference types can hold null already, there is no need for a nullable reference type. The syntax T? is shorthand for Nullable<T>, where T is a value type. The two variations are interchangeable. You can also use the operators == and != eg. if (i == null) i = 1;

In fact the nullable class is not a class. It is a struct. And this explains a lot. A struct is a value type. If supported you do not need the new keyword to create an instance (custom structs do need the new keyword). And when you assign the nullable (=struct) to another variable then you create a copy of that instance. You do not simply copy a reference, which would be much faster. Parameters and locals are created on the stack, members on the heap. As we are talking about value types, we now understand why variables themselves cannot be null. They can hold the value null though (see the following example code). Classes are more complex, you intent to modify them during their use. In contrast structs are best suited for small data which is not intended to be modified after the struct is created.

The nullable struct could look like this:

struct Nullable<T> where T : struct {
    private readonly bool _HasValue;
    private readonly T _Value;

    public Nullable(T xValue) {
        _HasValue = true;
        _Value = xValue;
    } // constructor

    public bool HasValue {
        get { return _HasValue; }
    } //

    public T Value {
        get {
            if (_HasValue) return _Value;
            throw new ArgumentException();
        }
    } //

    public T GetValueOrDefault() {
        return _Value;
    } //

} // struct

The struct “struct Nullable<T> where T : struct {}” is defined with “where T : struct”. This means the argument T has to be a value type (except a nullable, you cannot create nullables of nullables).
We will take a closer look at the “where T:” in the next post.

Enums (basics, advanced)

Enumerations offer an easy way to make your code legible. We are far away from Assembler programming and use words instead of numbers when possible. In an enum each word represents a number.

enum eOrder { Salad, Pizza, Spaghetti}

By default the first element (Salad) has the value of 0. Each following value is incremented by 1 (Pizza = 1, Spaghetti = 2).
You can define a value explicitly, otherwise it follows the standard increment.

enum eOrder { Salad = 100, Pizza, Spaghetti =  300}

static void Main(string[] args) {
    eOrder lOrder = eOrder.Salad;
    Console.WriteLine(lOrder + " :" + (int)lOrder);
    Console.WriteLine(eOrder.Pizza + " :" + (int)eOrder.Pizza);
    Console.WriteLine(eOrder.Spaghetti + " :" + (int)eOrder.Spaghetti);
    Console.ReadLine();
} //

example output:
Salad :100
Pizza :101
Spaghetti :300

You can also predefine the value type. The default is integer.

enum eOrder : byte { Salad = 100, Pizza, Spaghetti};

static void Main(string[] args) {
    eOrder lOrder = eOrder.Salad;
    Console.WriteLine(lOrder + " :" + (byte)lOrder);
    Console.WriteLine(eOrder.Pizza + " :" + (byte)eOrder.Pizza);
    Console.WriteLine(eOrder.Spaghetti + " :" + (byte)eOrder.Spaghetti);
    Console.ReadLine();
} //

example output:
Salad :100
Pizza :101
Spaghetti :102

And when you have to save space on the hard disk/in RAM or you need smaller packages to send across a network, then you can use bit fields where applicable. Simply add the “Flags” property.

[Flags]
enum eDays {
    None = 0x0,
    Monday = 0x1,
    Tuesday = 0x2,
    Wednesday = 0x4,
    Thursday = 0x8,
    Friday = 0x10,
    Saturday = 0x20,
    Sunday = 0x40,
    Weekend = 0x60
};

static void Main(string[] args) {
    eDays lDays = eDays.Saturday | eDays.Sunday;
    if (lDays.HasFlag(eDays.Saturday)) Console.WriteLine("Saturday is set");
    if (lDays.HasFlag(eDays.Sunday)) Console.WriteLine("Sunday is set");
    if (lDays.HasFlag(eDays.Sunday | eDays.Saturday)) Console.WriteLine("Weekend is set");
    if (lDays.HasFlag(eDays.Weekend)) Console.WriteLine("Weekend is set");
    Console.WriteLine(eDays.Weekend + " : " + ((int)eDays.Weekend).ToString("X2") + " == " + ((int)lDays).ToString("X2") );   // X2 => hexadecimal using 2 alphanumeric places
    Console.ReadLine();
} //

example output:
Saturday is set
Sunday is set
Weekend is set
Weekend is set
Weekend : 60 == 60

The next challenge for today is parsing strings:

static void Main(string[] args) {       
    eDays lDays = (eDays)Enum.Parse(typeof(eDays), "Thursday");  // needs try/catch block
    Console.WriteLine("first parsed result is : " + lDays);

    // does not need a try/catch block
    if (!Enum.TryParse("Friday", out lDays)) Console.WriteLine("Parser failed");
    else Console.WriteLine("second parsed result is : " + lDays);

    Console.ReadLine();
} //

example output:
first parsed result is : Thursday
second parsed result is : Friday

And now let’s parse integers and also iterate through all available enum values. If you assign arbitrary integers to enums, they will simply store the value. There is no validity check.

static void Main(string[] args) {
    eDays lDays = (eDays)8;
    Console.WriteLine("result 1 is : " + lDays);

    lDays = (eDays)0x80;
    Console.WriteLine("result 2 is : " + lDays); // oops, doesn't fail?            

    lDays = (eDays)0x140;
    Console.WriteLine("result 3 is : " + lDays); // doesn't fail again
    eDays[] lAllPossibleDays = (eDays[])Enum.GetValues(typeof(eDays));
    foreach (eDays x in lAllPossibleDays) {
        if (((int)lDays & (int)x) == (int)x) Console.WriteLine(x); // code not optimized in demo
    }

    Console.ReadLine();
} //

example output:
result 1 is : Thursday
result 2 is : 128
result 3 is : 320
None
Sunday

Exceptions (part 3, advanced)

For Windows Forms and WPF we have specific exceptions to deal with. Actually these are not really exceptions. They are events, which are raised whenever any unhandled exception occurs. “Unhandled” means there is nothing that catches exceptions and the entire stack did not come up with any solution. Nothing stopped the thread falling down to its lowest level, and even that level does not know what to do with the exception. You can eg. throw an exception on a button click to cause this behavior.
These events allow applications to log information about unhandled exceptions.

In Windows Forms the EventHandler is defined in System.Threading and is called ThreadExceptionEventHandler. If you do not define this event call then your application will crash when unhandled exceptions show up.

[STAThread]
static void Main() {
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.ThreadException += Application_ThreadException;
    Application.Run(new Form1());
} //

static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e) {
    Exception lException = (Exception)e.Exception;
    MessageBox.Show(lException.Message);
} //

The approach in WPF is similar. We are talking in Domains. Therefore we subscribe to AppDomain.CurrentDomain.UnhandledException .

public MainWindow() {
    InitializeComponent();
    AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;            
} //

void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) {
    Exception lException = (Exception)e.ExceptionObject;
    MessageBox.Show(lException.Message + "\nIsTerminating: " + e.IsTerminating);
} //

private void button1_Click(object sender, RoutedEventArgs e) {
    throw new Exception("user exception thrown");
} //

Exceptions (part 2, advanced)

Season’s Greetings!
Today we have a very short post about custom exceptions, which provide more specific information. Of course the custom exception has to inherit from System.Exception. Adding several constructors including a parameterless one is good practice.
The suffix “Exception” in your exception name is convention (eg. “OutOfMemory
Exception“, “FileNotFoundException“). Adding the Serializable attribute can be useful when you work across application domains. Properties help providing extra information.

Don’t use the System.ApplicationException class.
http://msdn.microsoft.com/en-us/library/system.applicationexception.aspx states:

If you are designing an application that needs to create its own exceptions, you should derive custom exceptions from the Exception class. It was originally thought that custom exceptions should derive from the ApplicationException class; however in practice this has not been found to add significant value.

In other words: ApplicationException is a relic of the past, where Microsoft intended developers to inherit all their custom exceptions from. But this has never become practice and custom exceptions now derive from the Exception class.

[Serializable]
public class UserNotFoundException : Exception {
    public string UserId { get; private set; }
            
    public UserNotFoundException(string xUserId) : base() {
        UserId = xUserId;
        base.HelpLink = "http://www.ohta.de";
    } // constructor

    public UserNotFoundException(string xUserId, string xMessage)
        : base(xMessage) {
        UserId = xUserId;
        base.HelpLink = "http://www.ohta.de";
    } // constructor

    public UserNotFoundException(string xUserId, string xMessage, Exception xInnerException)
        : base(xMessage, xInnerException) {
        UserId = xUserId;
        base.HelpLink = "http://www.ohta.de";
    } // constructor

    protected UserNotFoundException(SerializationInfo xSerializationInfo, StreamingContext xStreamingContext) {
        UserId = xSerializationInfo.GetValue("UserId", typeof(string)) as string;
    } // constructor

    public void GetObjectData(SerializationInfo xSerializationInfo, StreamingContext xStreamingContext) {
        xSerializationInfo.AddValue("UserId", UserId, typeof(string));
    }
} // class

Exceptions (part 1, advanced)

Exceptions are not errors, they are exceptions. They should not be used for code that can deal with errors. Exceptions are for situations that cannot be solved like running out of RAM or hard disk space. They are pretty slow, because they deal with the entire stack trace. Here is a short benchmark program:

static double DoSomeCalc(double d) {
    return d * 1.1;
} //
static double DoSomeCalc2(Exception e) {
    throw e;
} //

static void Exceptions1() {
    const int n = 10000000;
    double d = 1.0;

    Stopwatch lStopwatch = new Stopwatch();
    lStopwatch.Start();

    for (int i = 0; i < n; i++) d *= 1.1;
    Console.WriteLine("benchmark ms " + lStopwatch.ElapsedMilliseconds);

    lStopwatch.Restart();
    try { for (int i = 0; i < n; i++)  d *= 1.1; }
    catch (Exception) { throw; }
    Console.WriteLine("efficient try/catch block ms " + lStopwatch.ElapsedMilliseconds);

    lStopwatch.Restart();
    for (int i = 0; i < n; i++) {
        try { d *= 1.1; }
        catch (Exception) { throw; }
    }
    Console.WriteLine("inefficient try/catch block ms " + lStopwatch.ElapsedMilliseconds);
    Console.WriteLine();

    lStopwatch.Restart();
    for (int i = 0; i < n; i++) d = DoSomeCalc(d);
    Console.WriteLine("method call, benchmark ms " + lStopwatch.ElapsedMilliseconds);

    lStopwatch.Restart();
    try { for (int i = 0; i < n; i++)  d = DoSomeCalc(d); }
    catch (Exception) { throw; }
    Console.WriteLine("method call, efficient try/catch block ms " + lStopwatch.ElapsedMilliseconds);

    lStopwatch.Restart();
    for (int i = 0; i < n; i++) {
        try { d = DoSomeCalc(d); }
        catch (Exception) { throw; }
    }
    Console.WriteLine("method call, inefficient try/catch block ms " + lStopwatch.ElapsedMilliseconds);
    Console.WriteLine();

    Exception e = new Exception();  // only one instance, we exclude the creation time for the object in this test
    lStopwatch.Restart();
    for (int i = 0; i < 100; i++) {
        try { throw e; }
        catch (Exception) { }
    }
    Console.WriteLine("100 exceptions thrown in ms " + lStopwatch.ElapsedMilliseconds);

    lStopwatch.Restart();
    for (int i = 0; i < 100; i++) {
        try { DoSomeCalc2(e); }
        catch (Exception) { }
    }
    Console.WriteLine("method call, 100 exceptions thrown in ms " + lStopwatch.ElapsedMilliseconds);

    lStopwatch.Stop();
    Console.ReadLine();
} //

example output:
benchmark ms 2227
efficient try/catch block ms 2179
inefficient try/catch block ms 2201

method call, benchmark ms 2448
method call, efficient try/catch block ms 2436
method call, inefficient try/catch block ms 2431

100 exceptions thrown in ms 603
method call, 100 exceptions thrown in ms 652

The first three results are in line with each other. The code optimizer does the job and there is no visible impact on the outcome. The difference is more likely to be a result of context switching (threading).
And when we call a method the slowdown is also regular, no big impact of the try/catch blog.
But when exceptions are thrown, the system considerably slows down. 600 ms for just 100 exceptions is a disaster. And it gets even worse when you call a method, because the stack trace becomes longer. Imagine what happens when you have nested methods involved.

The conclusion is that throwing exceptions for the programmer’s convenience is bad practice. Exceptions must be avoided by all means. You’d rather perform a quick zero check than raise a DivideByZeroException.

Do not reuse exception objects, this is not thread safe. In general try to avoid re-throwing exceptions. Anyway, let’s see how to re-throw exceptions in case you need it:

a) Re-“throw” without any identifier. This preserves the original exception details.

static void Exceptions2() {
    int lZero = 0;
    try { int i = 4 / lZero; }
    catch (Exception) { throw; }
} //

static void Exceptions3() {
    try { Exceptions2(); }
    catch (Exception e) {
        Console.WriteLine("Message:        {0}", e.Message);
        Console.WriteLine("StackTrace:     {0}", e.StackTrace);
        Console.WriteLine("HelpLink:       {0}", e.HelpLink);
        Console.WriteLine("InnerException: {0}", e.InnerException);
        Console.WriteLine("TargetSite:     {0}", e.TargetSite);
        Console.WriteLine("Source:         {0}", e.Source);
    }
} //

Message: Attempted to divide by zero.
StackTrace: at ConsoleApplication1.Program.Exceptions2() in ….\Program.cs:line 1155
at ConsoleApplication1.Program.Exceptions3() in ….\Program.cs:line 1160
HelpLink:
InnerException:
TargetSite: Void Exceptions2()
Source: ConsoleApplication1

b) Re-throw the original exception. Add some more information.

static void Exceptions4() {
    int lZero = 0;
    try { int i = 4 / lZero; }
    catch (DivideByZeroException e) { throw new DivideByZeroException("Division by Zero", e); }
    catch (Exception e) { throw new Exception("Any Exception", e); } // will not be thrown in this example
} //

static void Exceptions5() {
    try { Exceptions4(); }
    catch (Exception e) {
        Console.WriteLine("Message:        {0}", e.Message);
        Console.WriteLine("StackTrace:     {0}", e.StackTrace);
        Console.WriteLine("HelpLink:       {0}", e.HelpLink);
        Console.WriteLine("InnerException: {0}", e.InnerException);
        Console.WriteLine("TargetSite:     {0}", e.TargetSite);
        Console.WriteLine("Source:         {0}", e.Source);
    }
} //

example output:
Message: Division by Zero
StackTrace: at ConsoleApplication1.Program.Exceptions4() in ….\Program.cs:line 1134
at ConsoleApplication1.Program.Exceptions5() in ….\Program.cs:line 1140
HelpLink:
InnerException: System.DivideByZeroException: Attempted to divide by zero.
at ConsoleApplication1.Program.Exceptions4() in ….\Program.cs:line 1133
TargetSite: Void Exceptions4()
Source: ConsoleApplication1

Events (part 3, advanced)

Events: Let’s go multithreading! We want the crème de la crème. Well, multitasking is also fine.

The code does not need to run in a specific sequence. The required independence is given. Again, there are many ways to use multithreading. An easy approach is to start a task in each method that is called by the event.

C# does support BeginInvoke() for delegates. This method is not supported by the .NET Compact Framework though. We don’t care, because our hardcore programs are for serious applications, definitely not for mobile phone apps. Let’s see how good BeginInvoke() works. Maybe we don’t have to reinvent the wheel.

BeginInvoke() initiates asynchronous calls, it returns immediately and provides the IAsyncResult, which can be used to monitor the progress of the asynchronous call.
EndInvoke() retrieves the results. It blocks until the thread has completed.

You have the following options after calling BeginInvoke():
1) Call EndInvoke() to block the current thread until the call completes.
2) Obtain the WaitHandle from IAsyncResult.AsyncWaitHandle, use its WaitOne() and then call EndInvoke().
3) Poll the IAsyncResult to check the current state, after it has completed call EndInvoke().
4) Pass a callback to BeginInvoke(). The callback will use the ThreadPool to notify you. In the callback you have to call EndInvoke().

public event EventHandler OnChange;

public void DoSomeWork(object sender, object e) {
    Thread.Sleep(2100);
    Console.WriteLine("Thread " + Thread.CurrentThread.ManagedThreadId + " mission accomplished!");
} //

public void RunMyExample() {
    OnChange += new EventHandler(DoSomeWork);
    //OnChange += new EventHandler(DoSomeWork);
    //OnChange += new EventHandler(DoSomeWork);

    IAsyncResult lAsyncResult;

    Console.WriteLine("Choice 1");
    lAsyncResult = OnChange.BeginInvoke(this, EventArgs.Empty, null, null);
    OnChange.EndInvoke(lAsyncResult);

    Console.WriteLine("Choice 2");
    lAsyncResult = OnChange.BeginInvoke(this, EventArgs.Empty, null, null);
    lAsyncResult.AsyncWaitHandle.WaitOne();

    Console.WriteLine("Choice 3");
    lAsyncResult = OnChange.BeginInvoke(this, EventArgs.Empty, null, null);
    while (!lAsyncResult.IsCompleted) {
        Thread.Sleep(500);
        Console.WriteLine("work still not completed :(");
    }

    Console.WriteLine("Choice 4"); 
    OnChange.BeginInvoke(this, EventArgs.Empty, (xAsyncResult) => {
            Console.WriteLine("callback running");
            OnChange.EndInvoke(xAsyncResult);
        }, null);

    Console.WriteLine("press return to exit the program");
    Console.ReadLine();
}//    

example output:
Choice 1
Thread 6 mission accomplished!
Choice 2
Thread 6 mission accomplished!
work still not completed 😦
work still not completed 😦
work still not completed 😦
work still not completed 😦
Thread 10 mission accomplished!
work still not completed 😦
press return to exit the program
Thread 6 mission accomplished!
callback running

After having lived such a nice life, we have to face a major issue with BeginInvoke(). Uncomment “//OnChange += new EventHandler(DoSomeWork);”, don’t get annoyed now!
You will get an error message saying

“The delegate must have only one target”.

Although the delegate class can deal with multiple targets, asynchronous calls accept just one target.

So let’s try something else.

    public event EventHandler OnChange;

    public void DoSomeWork(object sender, object e) {
        Thread.Sleep(2100);
        Console.WriteLine("Thread " + Thread.CurrentThread.ManagedThreadId + " mission accomplished!");
    } //

    public void RunMyExample() {
        OnChange += new EventHandler(DoSomeWork);
        OnChange += new EventHandler((sender, e) => { throw new Exception("something went wrong"); });
        OnChange += new EventHandler(DoSomeWork);

        EventHandler lOnChange = OnChange;
        if (lOnChange == null) return;   // just to demonstrate the proper way to call events, not needed in this example                
        foreach (EventHandler d in lOnChange.GetInvocationList()) {
            Task lTask = Task.Factory.StartNew(() => d(this, EventArgs.Empty));
            lTask.ContinueWith((i) => { Console.WriteLine("Task canceled"); }, TaskContinuationOptions.OnlyOnCanceled);
            lTask.ContinueWith((i) => { Console.WriteLine("Task faulted"); }, TaskContinuationOptions.OnlyOnFaulted);
            lTask.ContinueWith((i) => { Console.WriteLine("Task completion"); }, TaskContinuationOptions.OnlyOnRanToCompletion);
        }

        Console.WriteLine("press return to exit the program");
        Console.ReadLine();
    }//    

It seems that Microsoft has a serious bug here.This code does not execute properly each time. I guess it has to do with the asynchronous behaviour of StartNew(). It sometimes calls the wrong method DoSomeWork() three times and does not raise the exception.
It seems foreach overrides variable “d” before it is inserted in StartNew(). With a little tweak we can avoid this bug. We simply assign “d” to a new local variable. That way we have unique copies of “d”. Weird stuff, but that is the life of a coder sometimes.

public event EventHandler OnChange;

public void DoSomeWork(object sender, object e) {
    Thread.Sleep(2100);
    Console.WriteLine("Thread " + Thread.CurrentThread.ManagedThreadId + " mission accomplished!");
} //

public void RunMyExample() {
    OnChange += new EventHandler(DoSomeWork);
    OnChange += new EventHandler((sender, e) => { throw new Exception("something went wrong"); });
    OnChange += new EventHandler(DoSomeWork);

    EventHandler lOnChange = OnChange;
    if (lOnChange == null) return;   // just to demonstrate the proper way to call events, not needed in this example                
    foreach (EventHandler d in lOnChange.GetInvocationList()) {
        EventHandler e = d;
        Task lTask = Task.Factory.StartNew(() => e(this, EventArgs.Empty));
        lTask.ContinueWith((i) => { Console.WriteLine("Task canceled"); }, TaskContinuationOptions.OnlyOnCanceled);
        lTask.ContinueWith((i) => { Console.WriteLine("Task faulted"); }, TaskContinuationOptions.OnlyOnFaulted);
        lTask.ContinueWith((i) => { Console.WriteLine("Task completion"); }, TaskContinuationOptions.OnlyOnRanToCompletion);
    }

    Console.WriteLine("press return to exit the program");
    Console.ReadLine();
}//    

Example output:
press return to exit the program
Thread 11 mission accomplished!
Thread 10 mission accomplished!
Task completion
Task faulted
Task completion

This tiny tweak worked. You just have to know the compiler bugs. I hope this little notice saves you at least 3 hours of work.
You probably remember that we faced a similar issue in my post “Exiting Tasks (advanced)” https://csharphardcoreprogramming.wordpress.com/2013/12/11/exiting-tasks/ . I would suggest to only use Task.Factory.StartNew() with caution. Maybe it only happens in conjunction with lambda expressions.
The following code is also running very well. The variable “d” is not used directly in Task.Factory.StartNew().

...
 foreach (EventHandler d in lOnChange.GetInvocationList()) {
            Action a = () => d(this, EventArgs.Empty);
            Task lTask = Task.Factory.StartNew(a);
            lTask.ContinueWith((i) => { Console.WriteLine("Task canceled"); }, TaskContinuationOptions.OnlyOnCanceled);
            lTask.ContinueWith((i) => { Console.WriteLine("Task faulted"); }, TaskContinuationOptions.OnlyOnFaulted);
            lTask.ContinueWith((i) => { Console.WriteLine("Task completion"); }, TaskContinuationOptions.OnlyOnRanToCompletion);
        }
...

Events (part 2, advanced)

We are going to construct our custom event accessor now. It deals with additions and removals of subscriptions. Accessors do pretty much look like property definitions. But instead of set and get you have to use add and remove.

public class MyActionEvent4 {
    private object _Lock = new object();            // a new object simply to avoid lock conflicts
    private event EventHandler<MyArgs> _OnChange;
    private event EventHandler<MyArgs> OnChange {
        add {
            lock (_Lock) { _OnChange += value; }
        }
        remove {
            lock (_Lock) { _OnChange -= value; }
        }
    } //

    public void RaiseEvent() {
        lock (_Lock) {
            EventHandler<MyArgs> lHandler = _OnChange;
            if (lHandler == null) return;
            lHandler(this, new MyArgs(0));   
        }        
    }//
} // class

Now we have one big problem here. The RaiseEvent() method has to obtain a lock each time, which causes a serious impact on time sensitive programs. Luckily you do not need to care about changing subscriptions during the invocation. Delegate references are thread-safe, because they are immutable like strings. Let’s simply take the lock out of the RaiseEvent() method, et voilà!

public class MyActionEvent5 {
    private object _Lock = new object();
    private event EventHandler<MyArgs> _OnChange;
    private event EventHandler<MyArgs> OnChange {
        add {
            lock (_Lock) { _OnChange += value; }
        }
        remove {
            lock (_Lock) { _OnChange -= value; }
        }
    } //

    public void RaiseEvent() {
        EventHandler<MyArgs> lHandler = _OnChange;
        if (lHandler == null) return;
        lHandler(this, new MyArgs(0));   
    }//
} // class

It is clear that events are not delegates. They restrict access rights from outside of the event class. To describe events you could most likely say that they are wrappers around delegates.

Whenever an exception is thrown during an event call then all following calls will not be executed. And it is tricky to determine which calls were not executed, because the order of event calls is not guaranteed to be in sequence. In fact it does execute in sequence, but there is no guarantee.

static void EventExceptions1() {
    MyActionEvent3 lEvent = new MyActionEvent3();
    lEvent.OnChange += (sender, e) => Console.WriteLine("Executed subscription 1");
    lEvent.OnChange += (sender, e) => { throw new Exception("OMG!"); };
    lEvent.OnChange += (sender, e) => Console.WriteLine("Executed subscription 3");
    lEvent.RaiseEvent();
} //

So you have to deal with exceptions manually if you want to satisfy/execute as many event subscriptions as possible. You could add a try/catch block for each subscription. Or you could invoke the InvocationList yourself by calling the GetInvocationList() method [System.Delegate] and execute each item manually in a try/catch block. Let’s have a look at the following practical solution:

public class MyActionEvent6 {
    public event EventHandler OnChange = delegate { };

    public void RaiseEvent() {
        List<Exception> lExceptions = new List<Exception>();

        foreach (Delegate lHandler in OnChange.GetInvocationList()) {
            try { lHandler.DynamicInvoke(this, EventArgs.Empty); }
            catch (Exception ex) { lExceptions.Add(ex); }
        }

        if (lExceptions.Count > 0) throw new AggregateException(lExceptions);
    }//
} // class

static void EventExceptions6() {
    MyActionEvent6 lEvent = new MyActionEvent6();
    lEvent.OnChange += (sender, e) => Console.WriteLine("Executed subscription 1");
    lEvent.OnChange += (sender, e) => { throw new Exception("OMG!"); };
    lEvent.OnChange += (sender, e) => Console.WriteLine("Executed subscription 3");

    try { lEvent.RaiseEvent(); }
    catch (AggregateException ex) {
        foreach (Exception lException in ex.InnerExceptions) {
            Console.WriteLine(lException.InnerException.Message);
        }
    }
} //

Events (part 1, advanced)

Events link code dynamically together via subscriptions. There are many ways to achieve this. To better understand events, we will start with the old school approach. It is pretty much Java style. You would not do such in C#.

public interface IListener {
    void OnEvent(int xDummy);
} // interface

public class AnyClass {
    private List<Ilistener> _Listeners = new List<Ilistener>();

    public void AddListener(IListener xListener) {
        lock (_Listeners) { _Listeners.Add(xListener); }
    } //

    public void RemoveListener(IListener xListener) {
        lock (_Listeners) { _Listeners.Remove(xListener); }
    } //

    protected void RaiseEvent() {
        lock (_Listeners) {
            foreach (IListener lListener in _Listeners) lListener.OnEvent(0);
        }
    }//

    public void DoSomeCalc() {
        Console.WriteLine("calculating something");
        Console.WriteLine("done");
        Console.WriteLine("going to tell others");
        RaiseEvent();
    } //
} // class

public class MyLittleProgram : IListener {
    public void StartDemo() {
        AnyClass c = new AnyClass();
        c.AddListener(this);
        c.DoSomeCalc();
        c.RemoveListener(this);
    } //

    public void OnEvent(int xDummy) {
        Console.WriteLine("Hey, cool! I got a notification");
    } //
} // class

static void Main(string[] args) {    
    MyLittleProgram p = new MyLittleProgram();
    p.StartDemo();

    Console.ReadLine();
} //

Above example program uses a List that stores classes. An event is raised by iterating through that list and calling the desired method. This is a lot of code for something really simple.
In the post “Delegates (basics)” https://csharphardcoreprogramming.wordpress.com/2013/12/16/delegates-basics/ we have learned to use delegates. And let’s emphasize it again: We are talking about MulticastDelegates. In the post “Lambda expressions (advanced)” https://csharphardcoreprogramming.wordpress.com/2013/12/17/lambda-expressions-advanced/ we then came across Func and Action. The next step would be to make use of Action.

public class MyActionEvent {
    public Action OnChange { get; set; }

    public void RaiseEvent() {
        Action lAction = OnChange;
        if (lAction == null) return;
        lAction();
    }//
} // class

static void Main(string[] args) {
    MyActionEvent lEventClass = new MyActionEvent();
    lEventClass.OnChange += () => Console.WriteLine("I got a notification.");
    lEventClass.OnChange += () => Console.WriteLine("Me too.");
    lEventClass.RaiseEvent();

    Console.ReadLine();
} //

Notice that we used a local delegate variable (Action lAction = OnChange;) and did not call OnEvent directly. This is important in a multithreaded environment. Allthough it is unlikely, the event could still turn null before it gets raised.

Above code is much more legible now. But it is really bad practice. The event is accessible from outside. The class MyActionEvent loses control over the event. The Action OnChange is accessible and can be raised from outside the class. This is why C# implemented the “event” keyword. Code no longer uses public properties but public event fields, which are properly protected.
An event can only be assigned by using “+=”, whereas an Action can also be entirely overridden with “=”. It makes programming a little bit safer, you don’t run the risk of removing all previous subscriptions by mistake. Also events can only be raised by code within the same class. There is no way events could be raised from outside.

To make your life easier you can assign an empty delegate during the initialization process. By using “= delegate { };” there is no further need to check for the null condition, especially that no outside code can assign null to the event. Only code inside the class can assign null. Therefore the class is in full control of the event.

public class MyActionEvent2 {
    public event Action OnChange = delegate { };

    public void RaiseEvent() {
        OnChange();
        Console.WriteLine("number of event handlers: " + OnChange.GetInvocationList().Length);
    }//
} // class

Personally I do not like the approach with empty delegates. The number of delegates is artificially increased by one. A null check is pretty much using no time at all, so why should someone prefer to call an empty method each time an event is raised?

The next step is to replace the dirty Action by a proper delegate definition, which is EventHandler<>. By default its parameters are the sender object and some event arguments. This is a C# convention and should be followed. Surely you are familiar with such event calls from the Winforms/WPF environment.

public class MyArgs : EventArgs {
    public MyArgs(int xValue) {
        Value = xValue;
    } // constructor

    public int Value { get; set; }
} // class

public class MyActionEvent3 {
    public event EventHandler<myargs> OnChange;

    public void RaiseEvent() {
        EventHandler<myargs> lHandler = OnChange;
        if (lHandler == null) return;
        lHandler(this, new MyArgs(0));                
    }//
} // class

static void Main(string[] args) {
    MyActionEvent3 lEventClass = new MyActionEvent3();
    lEventClass.OnChange += (sender, e) => Console.WriteLine("Event raised, field value is: " + e.Value);            
    lEventClass.RaiseEvent();
    
    Console.ReadLine();
} //

Lambda expressions (advanced)

Well, I have used lambda expressions in previous posts already. I was expecting that you know them already.
A Lambda function does not have a name, therefore it is also refered to as anonymous function.
Let’s have a closer look now. In my last post I was introducing delegates and we started with the following example:

// methods
private double Multiply(double a, double b) { return a * b; }
private double Add(double a, double b) { return a + b; }

// a delegate for any of the above methods
private delegate double dCalc(double a, double b);

void Delegates1() {
    dCalc calc = Add; // creates a new delegate
    Console.WriteLine("Sum " + calc(6.0, 3.0));

    calc = Multiply; // creates a new delegate
    Console.WriteLine("Product " + calc(6.0, 3.0));

    Console.ReadLine();
} //

Above code can be shortened by using lambda expressions. It also becomes more legible then:

private delegate double dCalc(double a, double b);

void Lambda1() {
    dCalc calc = (x, y) => x + y;
    Console.WriteLine("Sum " + calc(6.0, 3.0));

    calc = (x, y) => x * y;
    Console.WriteLine("Product " + calc(6.0, 3.0));

    Console.ReadLine();
} //

(x, y) => x + y; is a lambda expression with x and y defined as doubles. The types were defined in the delegate dCalc, which has two doubles as input parameters and one double as return value. The “@” sign is pronounced “at”, likewise the “=>” sign is pronounced “go to” or “goes to”.
As usual you can use curly braces to group multiple statements:
(x, y) => { Console.WriteLine(“hello”); return x + y;}

You don’t have to use parentheses if you only have one parameter.
(x) => x + x;
equals
x => x + x;

And you don’t need the “return” when there is only one statement.
x => x + x;
equals
x => { return x + x; }

C# offers built-in types. They are Func and Action. You can use them to define delegates. Both can take between 0 and 16 parameters. Action has no return value, Func must define a return type in the last parameter.

void Lambda2() {
    // syntax  Func<first parameter type, second parameter type, return value type>
    Func<double, double, int> func = (x, y) => (int)(x + y);

    // syntax Action<first parameter type, second parameter type>
    Action<double, double> action = (x, y) => Console.WriteLine(x + y);
} //

Btw. you need empty parentheses whenever you don’t use any parameters.

Func<int> f = () => 2;

You can be more formal and declare types explicitly.

void Lambda3() {
    Func<double, double, int> func = (double x, double y) => (int)(x + y);
    Action<double, double> action = (double x, double y) => Console.WriteLine(x + y);
} //

If a delegate refers to a local variable it can happen that the local variable does not exist anymore at the time of the lambda expression/(code) execution. It is important to understand that C# is taking care of this problem. The lifetimes of local variables are extended to at least the lifetime of the longest-living delegate. This is called closure.

void Lambda4() {
    string s = "hello world";

    Action action = () => { Thread.Sleep(2000); Console.WriteLine(s); };
    Task.Factory.StartNew(action);

    // Exit the method before the task has completed.
    // This does not invalidate the string s !!!
} //

Delegates (basics)

A delegate is like an enhanced classical pointer. It is type-safe and needs a specific method signature. Delegates can invoke methods, thus they can be used for events.
To declare a delegate simply add the word “delegate” in front of a method definition.

// methods
private double Multiply(double a, double b) { return a * b; }
private double Add(double a, double b) { return a + b; }

// a delegate for any of the above methods
private delegate double dCalc(double a, double b);

Assign a method to a delegate and then use the delegate to call the method.

void Delegates1() {
    dCalc calc = Add; // creates a new delegate
    Console.WriteLine("Sum " + calc(6.0, 3.0));

    calc = Multiply; // creates a new delegate
    Console.WriteLine("Product " + calc(6.0, 3.0));

    Console.ReadLine();
} //

example output:
Sum 9
Product 18

You can use operators to add or remove delegates. The next example shows that a delegate can point to multiple methods. This can be done, because delegates inherit from the System.MulticastDelegate class, which in turn inherits from System.Delegate.

private delegate void dPrint();

private void PrintA() { Console.WriteLine("Print A"); }
private void PrintB() { Console.WriteLine("Print B"); }

void Delegates2() {
    Console.WriteLine("--------------------------------");
    dPrint print = PrintA;
    print += PrintB;
    Console.WriteLine("added A and B");
    print();

    Console.WriteLine("--------------------------------");
    print -= PrintA;
    Console.WriteLine("removed A");
    print();

    Console.ReadLine();
} //

example output:
——————————–
added A and B
Print A
Print B
——————————–
removed A
Print B

Delegates do have iterators. You can loop through and/or count them. By now you should easily understand that delegates have nothing to do with pointers (as eg. used in C++). They do not just point somewhere. A delegate is a complex class. And we are dealing with multicast delegates on top of that.

private delegate void dPrint();

private void PrintA() { Console.WriteLine("Print A"); }
private void PrintB() { Console.WriteLine("Print B"); }

void Delegates3() {
    dPrint print = PrintA;
    print += PrintB;
    print += PrintB;
    print();
    Console.WriteLine("number of invokes: " + print.GetInvocationList().GetLength(0));
    foreach (Delegate d in print.GetInvocationList()) {
        Console.WriteLine(d.Method.Name + "()");
    }

    Console.ReadLine();
} //

example output:
Print A
Print B
Print B
number of invokes: 3
PrintA()
PrintB()
PrintB()

There are some words to learn here:

Covariance describes a return value that is more derived than defined in the delegate.
Contravariance describes a method with parameters that are less derived than those defined in the delegate.
Invariant describes a generic type parameter that is neither marked covariant nor contravariant.
Variance Covariance and Contravariance are collectively called variance.

Covariance looks like standard polymorphism, whereas Contravariance seems counterintuitive. What is important to remember is that a covariant type parameter can be used as the return type of a delegate, and contravariant type parameters can be used as parameter types.

Contravariance was introduced in C# 4. Source code that did not compile in C# 3.5 is now compiling and running very well under C# 4. Contravariance is meaningful for write-only methods. So the input does not produce an output of the same hierarchy.

Covariance example:

class A { public int dummyA = 0; }
class B : A { public double dummyB = 0.0; }

delegate A dCovariance();

B Test() { return new B(); }

void Delegates4() {
    dCovariance covariance = Test;  // test returns class B, not class A as defined in the delegate

    foreach (Delegate d in covariance.GetInvocationList()) {
        Console.WriteLine(d.Method.Name + "()");
    }

    Console.ReadLine();
} //

example output:
Test()

Contravariance example:

class A { public int dummyA = 0; }
class B : A { public double dummyB = 0.0; }

void Test2(A xParameter) { return; }

delegate void dContravariance(B xClassB);

void Delegates5() {
    // The parameter in Test2() is of type class "A", but the
    // delegate was defined with a class "B" parameter.
    dContravariance contravariance = Test2;

    foreach (Delegate d in contravariance.GetInvocationList()) {
        Console.WriteLine(d.Method.Name + "()");
    }

    contravariance(new B());  // <= important !!!!

    Console.ReadLine();
} //

example output:
Test2()

When calling contravariance(…) we have to pass any class B instance as parameter. And the method Test2() has obviously no problems with this. Class B is more derived. It does make sense now that Test2() can be less derived, doesn’t it?

Contravariance will be discussed in more detail when looking at generic interfaces with the “in T” annotation. One commonly used contravariant interface is IComparer. Lean back for the moment and just have a quick look at a custom interface using the “in T” annotation. That should be enough for today.

interface IPerson<in T> {
    string Name { get; set; }
    int Age { get; set; }
}