Handles clause event handler execution order limits

Direct answer

No. Visual Basic .NET does not guarantee the execution order of multiple Handles methods that subscribe to the same event, and this is not a version-specific limit. There is also no documented numeric cap on how many methods may handle one event; the practical constraint is invocation order and maintainability, not a hard count.

Confirmed facts vs. likely explanation

Confirmed: Handles is compiler syntax sugar. The compiler generates a WithEvents backing field and emits AddHandler subscriptions for each method. The runtime then uses a multicast delegate, which commonly invokes entries in subscription order.

Likely explanation, not a contract: declaration order often matches invocation order because the compiler emits subscriptions in source order, but the language specification does not promise this. Observed order can change across compiler versions, build configurations, target architectures, explicit AddHandler/RemoveHandler calls, or simple reordering of handler methods. Treat any consistent sequence you observe as implementation behavior, not a guarantee.

Recommended pattern: explicit orchestrator

When side effects must run in a strict sequence, consolidate the logic into one Handles method that calls private procedures explicitly:

Private Sub OnStatusChanged(sender As Object, e As EventArgs) _
    Handles StatusPublisher.StatusChanged
    StepValidateInput()
    StepUpdateCache()
    StepRaiseSecondaryEvent()
End Sub

Remove redundant Handles clauses from the individual step methods, and avoid mixing Handles with dynamic AddHandler for the same event, because that makes the effective subscription list harder to audit.

Steps for this case

1. Identify every method that Handles the target event.
2. Move their bodies into named private procedures in the required order.
3. Keep a single Handles method as the orchestrator and call those procedures sequentially.
4. Add error handling inside the orchestrator based on whether one failing step should stop the remaining steps.
5. Delete the now-unused Handles clauses.

Verification

Build a minimal class with a WithEvents field and three Handles methods that append identifiers to a shared List(Of String). Raise the event and assert the list order. Repeat in Debug and Release, after reordering declarations, and after adding an explicit AddHandler/RemoveHandler call. Inspect generated IL with ILSpy or ILDASM only to confirm subscriptions exist; treat observed order as non-contractual.

One missing detail that could change this recommendation: are any subscriptions added dynamically with AddHandler, or are all handlers declared with Handles in the same class? Dynamic subscriptions require auditing call sites in addition to the orchestrator.