Event subscription and lifetime

What it is and why it exists

An event gives an object a notification point for “something happened” without requiring it to know who responds. The object that sends the notification is the publisher, an object that registers response code is a subscriber, and the registered method or lambda is an event handler . Button clicks, property changes, progress updates, and connection-state changes commonly use events.

Events are built on delegates, but they aren’t the same public interface. A public delegate field lets outside code replace, clear, or invoke its value. A public event only lets outside code use += and -=. That restriction leaves “when it happens” with the publisher and “what to do afterward” with subscribers.

An event can register several handlers, so a multicast delegate normally holds its invocation list. The notification still happens inside one process and is a synchronous method call by default. An event isn’t a message queue, and it doesn’t automatically create background work, switch threads, or persist messages.

Events fit when a component must announce a local state change to an unknown number of consumers without depending on those consumers. If a caller needs a return value, must control execution order, or must include failure in the publisher’s transaction, an ordinary method or explicit callback is usually clearer.

How it works

A restricted delegate member

public event EventHandler<OrderEventArgs>? Changed; declares a field-like event. Its type must be a delegate type. Code inside the class can read and invoke the event much like a delegate, while outside code can only register or remove handlers through the event’s add and remove operations.

EventHandler has the signature void (object? sender, EventArgs e). When a notification carries data, the usual choice is EventHandler<TEventArgs> with a domain-specific EventArgs subclass. sender identifies the source. A subscriber that already holds a properly typed source doesn’t need to cast this parameter merely to use it.

When a field-like event has no subscribers, its internal delegate is null. Publishers usually write Changed?.Invoke(this, args): invoke the handlers if present, otherwise finish. Outside code can’t write publisher.Changed?.Invoke(...) because the right to raise an event belongs to its declaring type.

The notification path looks like this. The add and remove operations update the invocation list; raising the event reads that list and calls its handlers.

Subscribe, raise, and unsubscribe

+= appends a handler to the invocation list. Adding the same handler repeatedly creates repeated entries. -= removes the last matching handler and has no effect when it finds no match. If you need to unsubscribe later, keep a named method or delegate instance instead of writing a seemingly identical lambda beside -=.

Raising a multicast delegate runs handlers synchronously in invocation-list order. The publisher’s thread remains inside those handlers until all return or one throws. Events have no built-in priority, retry, timeout, or exception isolation.

Every handler receives the same event-argument object in sequence. For a cancellable “before” event, a handler can set a shared Cancel property to true, and the publisher reads it after notification finishes. This pattern needs a clear contract: later handlers shouldn’t change an already true cancellation flag back to false.

References determine lifetime

An instance-method delegate contains its target object and method. While the publisher’s invocation list retains that delegate, the subscriber remains reachable through a strong reference . A local variable going out of scope isn’t enough to make the subscriber collectible.

When the publisher outlives the subscriber, the subscriber should use -= as its lifetime ends. Common designs unsubscribe in Dispose(), or make the higher-level object that created the relationship tear it down as well. Extra unsubscription isn’t necessarily useful when the two objects share a lifetime. Ownership, not a rote rule, decides.

A lambda can capture this, a service, or a large object graph. Its target stays alive with the delegate even when the handler body is tiny. Static events and application-wide singleton publishers deserve special scrutiny because they often outlive pages, requests, and temporary services.

Examples

Declare, raise, and remove a handler

This order exposes its status event, not the underlying delegate. The first status change writes an audit line. After removing the same audit delegate, the second change no longer notifies it.

StatusChanged is a field-like event, and only Order can invoke it. The event data is an immutable record, so a subscriber sees a snapshot of one transition. The program still prints the current status at the end: removing a subscriber doesn’t change the order’s own work.

Saving audit is about identity, not syntax preference. += and -= must operate on equal delegates; keeping the reference makes both intent and lifetime plain. A named method also provides stable add and remove operations.

Make a before-event cancellable

The second example sends a notification before submission. The first handler rejects a total above its limit. The second observes the same argument object, so it sees the cancellation state already set.

using System;

var checkout = new Checkout();

checkout.Submitting += (_, e) =>
{
    if (e.Total > 100m)
        e.Cancel = true;
};

checkout.Submitting += (_, e) =>
    Console.WriteLine($"observed cancel: {e.Cancel}");

Console.WriteLine($"accepted: {checkout.Submit(120m)}");

public sealed class SubmitEventArgs(decimal total) : EventArgs
{
    public decimal Total { get; } = total;
    public bool Cancel { get; set; }
}

public sealed class Checkout
{
    public event EventHandler<SubmitEventArgs>? Submitting;

    public bool Submit(decimal total)
    {
        var args = new SubmitEventArgs(total);
        Submitting?.Invoke(this, args);
        return !args.Cancel;
    }
}

# not executed here: the .NET SDK and C# compilers are unavailable

This API makes the cancellation decision after every synchronous handler runs. It doesn’t use handler return values because a multicast call would produce several results with no obvious combining rule. Mutable arguments work for this narrow purpose; immutable data is a better default for ordinary “already happened” events.

Handler order shouldn’t become an authorization rule. This example’s contract says handlers only move Cancel from false to true. If a later handler can restore submission, an earlier rejection loses effect. The publisher itself must perform any authorization that needs enforcement.

See exception propagation

The third example registers three handlers. When the second throws, the exception returns to the caller of Complete(), and the third handler doesn’t run.

using System;

var job = new Job();

job.Completed += (_, _) => Console.WriteLine("audit saved");
job.Completed += (_, _) => throw new InvalidOperationException("email failed");
job.Completed += (_, _) => Console.WriteLine("metrics updated");

try
{
    job.Complete();
}
catch (InvalidOperationException error)
{
    Console.WriteLine($"caught: {error.Message}");
}

public sealed class Job
{
    public event EventHandler? Completed;

    public void Complete()
    {
        Completed?.Invoke(this, EventArgs.Empty);
    }
}

# not executed here: the .NET SDK and C# compilers are unavailable

A publisher can’t assume every subscriber receives a notification. If “try every handler” is part of the contract, the publisher must obtain the invocation list, call each entry while recording failures, and define how multiple errors reach the caller. Don’t apply this policy silently to every event; it changes the error semantics.

Nor should a handler swallow every exception. It can handle failures from which it can recover; other failures belong at the system’s chosen error boundary. Whether audit, email, and metrics may fail independently is an application decision, not one the event keyword makes.

Tie a subscription to an object’s lifetime

The final example subscribes a panel in its constructor and removes the same named method in Dispose(). The second raise, after the using block, no longer calls the panel. The subscription now follows the object’s useful scope.

using System;

var ticker = new Ticker();

using (var panel = new StatusPanel(ticker))
{
    ticker.Tick();
}

ticker.Tick();
Console.WriteLine("done");

public sealed class Ticker
{
    public event EventHandler? Ticked;

    public void Tick() => Ticked?.Invoke(this, EventArgs.Empty);
}

public sealed class StatusPanel : IDisposable
{
    private readonly Ticker _ticker;

    public StatusPanel(Ticker ticker)
    {
        _ticker = ticker;
        _ticker.Ticked += OnTicked;
    }

    private void OnTicked(object? sender, EventArgs e) =>
        Console.WriteLine("panel refreshed");

    public void Dispose() => _ticker.Ticked -= OnTicked;
}

# not executed here: the .NET SDK and C# compilers are unavailable

Here Dispose() ends a subscription; it doesn’t imply that the object owns unmanaged resources. The pattern is still appropriate because it expresses a managed relationship that must end deterministically. Callers must actually dispose the panel. Implementing the interface alone performs no cleanup.

Some frameworks already provide load and unload hooks, subscription tokens, or weak-event mechanisms. Prefer the framework’s lifetime model when it has one. Handwritten IDisposable works for ordinary objects with clear ownership, but several places shouldn’t have to guess who removes one subscription.

Pitfalls

Unsubscribing an old lambda with a new one

Fix: when a subscription must be removed, store its handler in a field or local delegate, or use a named method. Raise the event again after removal and assert that the handler stays silent. Merely checking that -= compiles proves nothing.

Forgetting that a long-lived publisher retains subscribers

Fix: decide who creates and removes the subscription, then unsubscribe at that same lifetime boundary. Prefer a testable IDisposable path or framework lifecycle hook. Don’t begin with a generic weak-event implementation that hides uncertain ownership.

Treating a synchronous event as an async pipeline

Fix: if completion, cancellation, and errors must return to the publisher, define an explicit async contract that returns Task and specifies sequential or parallel handling. A genuine fire-and-forget notification still needs an observable error channel rather than relying on process-level unhandled errors.

Assuming every handler runs

Fix: the publisher should perform work required for its own invariants and protect resource cleanup with try/finally. Invoke handlers individually and aggregate or record failures only when the event’s contract explicitly calls for isolation.

Treating ?.Invoke as a threading solution

Fix: document the raising thread and reentrancy rules. UI subscribers should switch through their framework’s dispatcher, and shared state needs suitable synchronization. Unsubscribing stops future lists from including a handler; it can’t recall an invocation already in flight.

Letting outside handlers maintain publisher invariants

Fix: complete and validate the publisher’s own state change before raising an “already happened” event. A cancellable “about to happen” event may collect opinions, but the publisher remains responsible for final authorization and consistency checks.

Further reading

• Events in the C# programming guide
• Subscribe to and unsubscribe from events
• Standard .NET event patterns
• The event keyword
• C# language specification: events
• Delegate.GetInvocationList