Delegates and events look almost identical at the declaration site. Both hold a chain of methods, both are invoked the same way, both use += and -= to add and remove handlers. The difference is who is allowed to do what to them from outside the class, and that difference is the whole reason event exists as a separate keyword. This lesson is the synthesis lesson for the section: a side-by-side comparison, a decision rule, and a tour of the bugs that show up when someone picks the wrong shape.

By now the pieces are familiar: a delegate type holds a reference to a method, a multicast delegate holds a chain of methods invoked in order, and an event is a delegate exposed through a pair of restricted accessors. The natural follow-up: when you want a class to publish notifications, should the field be a plain delegate or an event?

Both shapes compile. Both work. The two snippets below define the same conceptual hook on a Cart: a way for outsiders to subscribe to "an item was added" notifications.

From the inside, both classes raise the notification the same way: a null-conditional ?.Invoke(name). From the outside, a subscriber writes cart.ItemAdded += OnItemAdded; either way. The two snippets look interchangeable, and that is exactly the problem. The event version gives up almost nothing in convenience and gains a wall of protection that the plain delegate version cannot offer.

The rest of this lesson is about what that wall protects against.

The clearest way to see the gap is to write a small program that does the suspicious things on both. We will define two carts, hand each one to a subscriber, and then watch what an outsider can do to break the subscription.

Identical output, identical wiring, identical look. So far the two shapes are indistinguishable. The split shows up when a second outsider, not the original subscriber, tries to interact with the cart.

Imagine some other module getting a reference to cart1 (the delegate version). That module can do four things the original subscriber never expected:

Each of those lines compiles. The original subscribers (EmailNotifier, SmsNotifier) have no way to defend themselves; the cart handed out a writable field, and once you have a writable field, anyone holding the reference can do anything with it.

Now try the same four operations on cart2 (the event version):

Four lines, four compile errors. The event keyword tells the compiler "this thing exists to be subscribed to and unsubscribed from, and that is the only contract outsiders are allowed to use." The class that declared the event is still free to invoke, assign, or null it from inside its own type. Everyone else gets += and -= and nothing more.

That single restriction is most of what the event keyword does. The rest of the lesson is filling in the implications.

The previous section showed the four operations the event keyword blocks. Now look at them one at a time and understand what each one would actually break if it were allowed.

External Invocation

When a publisher declares an event, the contract is roughly "I'll raise this when something interesting happens." Subscribers count on that contract. They don't expect the event to fire because some unrelated module decided to call Invoke from the outside.

With a plain delegate field, anything that holds a reference to the publisher can raise the notification:

The subscriber has no way to tell the two notifications apart. The fake one came in through the same channel as the real one. If OrderTracker.StatusChanged were declared as an event instead, the external Invoke line would not compile, and the only path that can raise the notification is Ship, which is exactly what subscribers expected.

Whole-Chain Replacement

A subscriber that writes cart.ItemAdded += OnAdded thinks of it as adding itself to a list. The reality with a public delegate field is that anyone can replace the whole list with a single assignment:

EmailAlert is gone. The original += was overwritten the moment someone wrote = somewhere else. This is one of the most common production bugs in code that exposes raw delegate fields: a developer somewhere writes inv.StockLow = ... thinking they're initializing the field, and silently wipes everyone else's subscription.

Declaring StockLow as an event makes the = line a compile error from outside the class, which is the entire point. Inside the class, the declaring type is still allowed to write StockLow = null; to clear all subscribers, but that's an explicit decision made by the author of the type, not a mistake made by a caller.

Wiping Subscribers

The special case of replacement is = null, which sets the field to no subscribers at all:

This is the most catastrophic version of the previous bug. Every subscriber, including ones from completely unrelated modules, just vanishes. With an event, the line is illegal outside the declaring type. With a delegate field, the line silently destroys every subscription in the application.

Reading the Chain

The fourth operation, reading the multicast chain into a variable, is less destructive but still leaks an implementation detail. With a plain delegate field, an outsider can grab the Delegate and inspect, copy, or save it:

That code can introspect every subscriber, which usually isn't supposed to be public information. With an event, the read is a compile error outside the declaring type, so the subscriber list stays private. The declaring type can still read it internally, which is how the event raises notifications in the first place.

A capability-by-capability view of what each shape allows. "Public delegate field" means a field declared as public Action<...> Foo;. "Public event" means public event Action<...> Foo;. Each row asks: when external code holds a reference to the publisher, can it do this?

The bottom rows are the most important. The runtime cost is identical, so the only thing you're trading is convenience versus encapsulation. Almost every time, encapsulation wins for public hooks. The exception is when you genuinely want a single overridable callback (a strategy parameter, a single hook on an object only you own), and in that case a delegate field, an Action, or a method parameter is the cleaner shape.

A picture of the two shapes side by side:

The diagram captures the asymmetry: with a delegate field, the publisher and the outsider have the same set of capabilities. With an event, the publisher keeps the full set, and the outsider is locked down to just subscribe and unsubscribe.

Knowing the differences in capability is half the picture. The other half is knowing which bugs follow from picking the wrong shape, and how the right shape eliminates them at the source.

The Accidental Wipe

The most frequent bug with a public delegate field: someone uses = instead of += and silently destroys every subscriber that came before. Easy to write, hard to spot in review, fatal in production.

The email and SMS subscribers are silently gone. Convert OrderShipped from a public delegate field into a public event, and the offending line hub.OrderShipped = msg => ... no longer compiles. The bug becomes impossible to introduce at all.

Outside Code Raising the Notification

The other classic bug: outside code calling Invoke on a publisher's delegate field and faking a notification. Subscribers can't tell whether they received a real event or a forgery.

Both messages look the same to the subscriber. Switch the field to an event, and the second line stops compiling, because outside code is no longer allowed to invoke the event. Subscribers regain the guarantee that the only thing that can raise StockLow is Inventory itself.

Forgetting to Unsubscribe

This one is shape-agnostic; both delegate fields and events have it. When a subscriber registers and never unregisters, the publisher holds a reference to it, which keeps it alive in the GC's eyes for as long as the publisher is alive.

The fix is symmetric and applies to both shapes: pair every += with a -= when the subscriber is done. A common pattern is to do this in a Dispose method or a try/finally block so the unsubscription happens even if something throws.

This bug doesn't go away by switching to events. The event keyword protects you from outside misuse, not from your own forgetful subscriber. Long-lived publishers with short-lived subscribers are still a leak source, and weak event patterns or explicit unsubscribe is the answer either way.

Race Conditions on Raise

Both shapes have a subtle threading bug if you ever raise from a thread different from the one doing the subscription. Consider this naive raise:

Between the null check and the call, a different thread could unsubscribe the last handler and the delegate field could become null. The result is a NullReferenceException in the call itself. The fix is the field-copy or null-conditional pattern:

?.Invoke reads the field exactly once into a hidden local, checks it for null, and then invokes the local. Other threads can change the field afterward, but the local copy is stable. This is one of the small reasons modern C# code prefers ?.Invoke(...) over the older if (Foo != null) Foo(...) style.

The event keyword does not save you from this bug. It's a publisher-side concern that applies whether you used event or a plain delegate. Use ?.Invoke consistently and the race goes away.

A Throwing Subscriber Short-Circuits the Chain

Multicast delegates invoke their handlers one at a time, in the order they were added. If one handler throws, the rest of the chain never runs. This isn't a "delegate vs event" difference (both shapes have it, because both ride on the same multicast machinery), but it shows up in event-driven designs and is worth knowing about.

The SMS subscriber never received the notification. The middle subscriber threw, and the exception propagated up through the multicast machinery, skipping every handler that hadn't run yet.

The fix when you actually need every subscriber to fire is to enumerate the invocation list manually and catch around each call:

This pattern isn't free (it iterates the list and catches one by one), but it's the standard recipe for "all subscribers must run regardless of what any one of them does." Most application code can ignore the subtlety; framework code and infrastructure publishers usually need to handle it.

After all the syntax and rules, the decision in practice comes down to two questions:

The decision flowchart:

A few concrete cases to make the rule less abstract:

The pattern in the table is consistent: if the question is "who can subscribe?" and the answer is "anyone who wants to listen," use event. If the question is "what callback should this method use?" or "what strategy does this object hold?", use a plain delegate.

One more piece of advice worth repeating: when in doubt, use event. The runtime cost is identical, and the protection is real. Converting an event to a plain delegate field later is a one-line change; converting a delegate field to an event after it's been misused for months is a refactor.

The Exception Handling section switches focus from event-driven communication to error-driven control flow. Many of the threading and "what runs when" subtleties from this section reappear in different forms, especially around exceptions that propagate out of subscribers and exception filters that decide which catch block wins. The encapsulation instincts you built here ("only the declaring type should be allowed to do this") will guide the design of custom exception types just as they guided the choice between delegate and event in this section.