Sequence of execution in multicast delegates in c#

Question

I read that

If you are using multicast delegates, you should be aware that the order in which methods chained to the same delegate will be called is formally undefined. You should, therefore, avoid writing code that relies on such methods being called in any particular order.

But when I experimented using this code

using System;
namespace Wrox.ProCSharp.Delegates
{
    class Program
    {
        static void One()
        {
            Console.WriteLine("watch when i occur");
            throw new Exception("Error in watching");
        }
        static void Two()
        {
            Console.WriteLine("count");
        }
        static void Three()
        {
            Console.WriteLine("great");
        }
        static void Main()
        {
            Action d1 = Two;
            d1+=Two;
            d1+=Two;
            d1+=Two;
            d1+=One;
            d1+=Three;
            d1+=Three;
            d1+=Three;

            Delegate[] delegates = d1.GetInvocationList();
            foreach (Action d in delegates)
                try
                {
                    d1();
                }
                catch(Exception)
                {
                    Console.WriteLine("Exception Caught");

                }
        }
    }
}

this is the output I got

count
count
count
count
watch when i occur
Exception Caught
count
count
count
count
watch when i occur
Exception Caught
count
count
count
count
watch when i occur
Exception Caught
count
count
count
count
watch when i occur
Exception Caught
count
count
count
count
watch when i occur
Exception Caught
count
count
count
count
watch when i occur
Exception Caught
count
count
count
count
watch when i occur
Exception Caught
count
count
count
count
watch when i occur
Exception Caught

Clearly the delegate is executing in the very specified order I wrote it in, and none of the Three() methods executes before the One() method which throws exception.

So is there something I am missing or actually methods in delegates executes in specified order and what I read from the book meant something else.

Answer 1

undefined - behavior is specified to be arbitrary (like what happens after you forget your wife's birthday...) so depending on arbitrary behaviour is potentially dangerous.

It could be that 5 years from now, Microsoft releases .NET 7 and your program's result changes. That is "undefined" meaning, no amount of measuring today will give you any comfort for the next release, or even between your computer and Fred's computer. So observing it is only interesting, but not useful for reliability. And relying on what you observed is technically wrong.

Sometimes a vendor will specifically document something as undefined to leave themselves flexibility in the implementation.

Answer 2

"Formally undefined" simply means: whatever happens is an implementation detail; it might work the way you would naturally expect; it might work completely different, and either is entirely valid. There is no demand mande on implementors that it behaves in any particular order. Further, this might change between framework versions, targets, and implementations.

Basically: even if it does what you expect and want: don't rely on it continuing to do so.