Urgent: Event Handler Recursion

Does anyone know what the exact behavior of the following scenario would be:

1. Class c1 has an event e1.
2. Class c2 has an event handler eh1
3. Instance c2a's eh1 method is attached as a handler for the event c1a.e1.
4. Event c1a.e1 is raised once.
5. Inside the c2a.eh1 handler, 2 new instances of c2 (c2b and c2c) are instantiated, and their eh1 methods are attached as handlers for the same event c1a.e1.

So the question is, will the method eh1 get called 1 time, or 3 times, or is it ambiguous?

Or in other words, at what point during the raising of an event does adding/removing handlers stop applying to the event already being raised?

LVL 24
Who is Participating?

Improve company productivity with a Business Account.Sign Up

gregoryyoungConnect With a Mentor Commented:
as for implementational detail or guarenteed .... this is the best I could find in the C# language specification

Invocation of a delegate instance whose invocation list contains multiple entries proceeds by invoking each of the methods in the invocation list, synchronously, in order. Each method so called is passed the same set of arguments as was given to the delegate instance. If such a delegate invocation includes reference parameters (Section, each method invocation will occur with a reference to the same variable; changes to that variable by one method in the invocation list will be visible to methods further down the invocation list. If the delegate invocation includes output parameters or a return value, their final value will come from the invocation of the last delegate in the list.

I could not however find anything where they deal with adding a delegate during the invocation of a delegate.

I would assume your second case to be no ...

using System;

namespace ConsoleApplication11

      public delegate void FooDelegate();
      public class foo
            public event FooDelegate Fooed;
            private int i=0;
            public string name;

            public void OnFoo()
                  if (Fooed != null)

            public void eh1()
                  Console.WriteLine(name + ":eh1 called");
                  foo f1 = new foo();
                  foo f2 = new foo();
                  f1.name = "f1:" + i.ToString();
                  f2.name = "f2:" + i.ToString();
                  this.Fooed += new FooDelegate(f1.eh1);
                  this.Fooed += new FooDelegate(f2.eh1);

            static void Main(string[] args)
                  foo f = new foo();
                  f.name = "f";
                  f.Fooed += new FooDelegate(f.eh1);
                  for(int i=0;i<10;i++)
                        Console.WriteLine("Loop " + (i+1).ToString());

add does not appear to apply (atleast in this case) until the next time the event is called. Subtract on the other hand appears to work so long as the event has not yet been called previously.

Justin_WAuthor Commented:
>> add does not appear to apply (atleast in this case) until the next time the event is called.
>> Subtract on the other hand appears to work so long as the event has not yet been called previously.

Thanks Greg!

Do you have any clue as to whether that behavior is guaranteed or merely an implementation detail?  Specifically, do you know whether the behavior may be different when there are multiple Events being handled and if some of the instances are defined in VB.NET assemblies and some in C# assemblies?  I don't want to rely on ambiguous behavior, but it would be really helpful if you happen to know for sure.
What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

Justin_WAuthor Commented:
Thanks!  That helps a lot.
sorry I couldnt help more mate, perhaps the CLR specification would hold something ? It appears atleast at face value to be an implementational detail.
Justin_WAuthor Commented:
You helped a lot.  I agree about the "implementation detail" part.  Based on your test, and the C# spec., and on the way order of execution is determined for event handlers defined in different classes, it seems like semi-predictable ambiguity is the best I can hope for.  As long as it doesn't cause any runtime errors (which both our tests seem to indicate is the case), I think I can safely raise the event inside a loop (with a special exit condition) so that it keeps getting raised until the system arrives at a rest state.  Thanks again.
Justin_WAuthor Commented:
I've posted a semi-related followup question here:

If anyone can provide any insight on it, I'd really appreciate it.  Thanks!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.