Raising Events in C#: Syntax, Safety, and Common Pitfalls

c# raise event requires a clear understanding of the core syntax, runtime behavior, and practical implementation patterns demonstrated in the examples below.

Raising an event in C# is a common task, but the way you invoke it affects reliability, thread safety, and maintainability. This article covers the core pattern, custom event arguments, safe invocation, and the pitfalls that appear in real code.

The Basic Event Pattern

In C#, an event is a member that allows subscribers to attach handler methods. The declaration uses the event keyword with a delegate type, typically EventHandler or EventHandler<T>. To raise the event, you invoke it like a method, passing the sender and event arguments.

public class Button
{
    public event EventHandler? Clicked;

    public void SimulateClick()
    {
        Clicked?.Invoke(this, EventArgs.Empty);
    }
}

The ?.Invoke syntax checks whether the event has any subscribers before calling. If there are none, the invocation is skipped. This is the standard way to raise an event in modern C#.

Creating Custom Event Arguments

When an event needs to carry data, derive a class from EventArgs and add properties. This keeps the event signature stable and avoids breaking subscribers when new data is added later.

public class TemperatureChangedEventArgs : EventArgs
{
    public double OldTemperature { get; }
    public double NewTemperature { get; }

    public TemperatureChangedEventArgs(double oldTemp, double newTemp)
    {
        OldTemperature = oldTemp;
        NewTemperature = newTemp;
    }
}

Then declare the event with EventHandler<TemperatureChangedEventArgs> and raise it with a constructed argument object. Subscribers can read the properties without casting.

Raising Events Safely with the Null-Conditional Operator

The null-conditional operator ?. is the recommended way to raise an event. It performs a single atomic read of the invocation list and then invokes it if non-null. This prevents a NullReferenceException when no subscribers exist.

public void UpdateTemperature(double newTemp)
{
    var oldTemp = _temperature;
    _temperature = newTemp;
    TemperatureChanged?.Invoke(this, new TemperatureChangedEventArgs(oldTemp, newTemp));
}

The ?.Invoke is not thread-safe in the sense that a subscriber can be removed between the null check and the invocation. However, because the invocation list is immutable in .NET, the delegate captured by ?. is a snapshot. This means the event will be raised to the subscribers that were present at the moment of the check, even if one is removed concurrently. This is usually acceptable, but if you need a strict snapshot, you can copy the delegate to a local variable first.

Thread Safety and Event Raising

When events are raised from multiple threads, you must consider the state of the invocation list. The ?.Invoke pattern already takes a snapshot, but there is a subtle race: if a subscriber is removed after the snapshot, the event still fires for that subscriber. This is generally safe because the delegate is immutable, but it can lead to unexpected behavior if the subscriber's object is being disposed.

If you need to guarantee that the event is raised exactly to the subscribers at a specific point in time, use a local copy:

var handler = TemperatureChanged;
if (handler != null)
{
    handler(this, new TemperatureChangedEventArgs(oldTemp, newTemp));
}

This copies the delegate reference to a local variable before the null check. The copy is a snapshot of the invocation list at that moment. However, this still does not prevent a subscriber from being removed after the copy; it only ensures the copy is consistent. For strict synchronization, you would need a lock around the event add/remove and raise operations, but that can introduce deadlock risks if subscribers call back into the raising object.

Raising Events from Background Threads

If your event is raised from a background thread and subscribers expect to update the UI, you need to marshal the call to the UI thread. The SynchronizationContext class provides a way to capture the current context and post the invocation back to it.

public void RaiseEventFromBackground()
{
    var context = SynchronizationContext.Current;
    // ... do work ...
    context?.Post(_ => EventRaised?.Invoke(this, EventArgs.Empty), null);
}

This is a common pattern in desktop and mobile applications. In ASP.NET Core, the synchronization context is often null, so this pattern is less relevant. The key is to understand that the event itself is not thread-aware; the raising code must decide how to deliver the invocation.

Common Mistakes When Raising Events

One frequent mistake is forgetting the null check, which causes a NullReferenceException when no subscribers exist. Another is raising the event with null as the sender when the event is defined on an instance; the sender should be this unless there is a strong reason otherwise. Also, modifying the event arguments after the event has been raised can confuse subscribers, especially if the same arguments object is reused.

Another subtle issue is raising an event inside a lock. If a subscriber tries to access the same lock, you get a deadlock. Avoid holding locks while invoking event handlers. Instead, copy the necessary state and raise the event outside the lock.

Choosing Between EventHandler<T> and Custom Delegate

The EventHandler<T> pattern is the .NET standard and should be your default choice. It provides a consistent signature and works with the built-in event designer tools. A custom delegate is only useful when you need a different return type or a different parameter list. For example, an event that allows subscribers to cancel an operation might use a delegate that returns a boolean.

public delegate bool ValidatingEventHandler(object sender, ValidationEventArgs e);

But this is rare. Most events should use EventHandler<T> for consistency and maintainability. If you need to support multiple subscribers and each can influence the outcome, you need a different design, such as a collection of handlers or a pipeline, rather than a standard event.