[matt-edmondson]

Fixes #66

Problem

DoInvokes raised BeginInvokeFailed in a plain foreach. If a handler threw on one failure, the exception escaped DoInvokes and the remaining failures were discarded. For example, 3 failed actions produced 1 report. It also read the event twice (is null, then ?.Invoke), so if the last handler unsubscribed in between, every failure was dropped and nothing was thrown.

Change

• Takes one handler snapshot, which is used for both the null check and the calls.
• Raises each failure in its own try/catch, so a throwing handler still receives every later failure.
• If any handler call threw, DoInvokes throws an AggregateException at the end. It holds each handler exception, followed by the failure that handler was handling.
• The XML docs (event remarks and the DoInvokes exception docs) and the README event table now describe this.

Tests

• New test ThrowingHandlerStillReceivesEveryLaterFailure: 3 failures, and a handler that throws on the first. It asserts that the handler saw fail 0, fail 1, fail 2, that the aggregate holds [handler threw, fail 0], and that a later pump has nothing left to report.
• On main the test fails (DoInvokes throws InvalidOperationException directly, not AggregateException). With the fix it passes.
• dotnet test on the branch: 41 run, 41 passed, 0 failed.
• Note: main CI currently fails at pack (No release since v1.4.4 (Oct 9): every main CI run since Oct 13 fails at pack on package validation (CP0016/CP0001/CP0002…) after the Polyfill 11.4.5 bump #86), which is unrelated to this change.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[matt-edmondson]

SonarCloud findings on this PR:

• S3776 (cognitive complexity of DoInvokes, 16 > 15): fixed in 9bc6d08. The reporting now lives in ReportBeginInvokeFailures, and Sonar no longer reports it.
• S3264 ("Remove the unused event BeginInvokeFailed"): left as is, because it's a false positive. The event is still raised. ReportBeginInvokeFailures copies it into a local handler and invokes that copy, which Sonar's rule doesn't trace. The local copy is the point of the fix: the old code read the event once for the null check and again for the invoke, and a handler unsubscribing in between would drop every failure. ThrowingHandlerStillReceivesEveryLaterFailure and the existing handler tests show the event firing. The finding can be marked as a false positive in SonarCloud.

---

Generated by Claude Code