🎯 Repository Quality Improvement — Exception Handling and Error Recovery Patterns

[Evangelink]

🎯 Repository Quality Improvement Report — Exception Handling and Error Recovery Patterns

Analysis Date: 2026-05-21
Focus Area: Exception Handling and Error Recovery Patterns
Strategy Type: Custom (Reuse-inspired deep dive)

Executive Summary

This analysis examined exception handling patterns across the microsoft/testfx repository (2,919 C# source files). The repository demonstrates strong exception handling foundations with 1,249 ConfigureAwait usages, 82 exception filters, and 211 nameof usages in exceptions. However, several modernization opportunities and consistency gaps exist:

Key Findings:

• Zero adoption of ArgumentNullException.ThrowIfNull (.NET 6+ helper) despite 181 ArgumentNullException throws
• 5 instances of throw ex; anti-pattern that lose stack traces (in ClassCleanupManager.cs)
• 50 async void methods creating unhandled exception risk vectors
• 199 hardcoded exception messages vs 121 localized ones (62% hardcoded rate)
• Minimal custom exception infrastructure: Only 9 custom exception types, 3 missing standard constructors

The codebase excels at async exception safety (1,249 ConfigureAwait calls) and sophisticated exception filtering (82 when clauses). These strengths can be leveraged to address the identified gaps through targeted improvements.

Full Analysis Report

Focus Area: Exception Handling and Error Recovery Patterns

Current State Assessment

Metrics Collected:

Metric	Value	Status
Total C# source files	2,919	📊
Files with catch blocks	134	✅
Files with throw statements	887	✅
Top exception thrown	InvalidOperationException (266)	✅
Custom exception types	9	⚠️
ConfigureAwait usage	1,249	✅
Exception filters (when clauses)	82	✅
ArgumentNullException.ThrowIfNull adoption	0	❌
throw ex; anti-patterns	5	⚠️
Async void methods	50	⚠️
Exception documentation tags	159	⚠️
Hardcoded exception messages	199	⚠️
Localized exception messages	121	✅
Bare throw; (correct pattern)	32	✅
ExceptionDispatchInfo usage	9	✅
AggregateException handling	42	✅

Exception Type Distribution

Top 10 Exception Types Thrown:

1. InvalidOperationException: 266
2. ArgumentNullException: 181
3. NotImplementedException: 171
4. ArgumentException: 72
5. NotSupportedException: 48
6. ArgumentOutOfRangeException: 26
7. PlatformNotSupportedException: 19
8. TypeInspectionException: 17 (custom)
9. AssertFailedException: 16 (custom)
10. FormatException: 15

Custom Exception Types:

• UnitTestAssertException (abstract base) — public API, properly serializable
• AssertFailedException — two versions (TestFramework & MSTest.Engine)
• AssertInconclusiveException — TestFramework assertion outcome
• MSTestException — internal TestFramework exception
• AdapterSettingsException — internal adapter configuration errors
• TypeInspectionException — internal reflection failures
• TestFailedException — internal test execution failures
• InvalidManagedNameException — internal name parsing failures
• MessageFormatException — internal message formatting errors

Findings

Strengths

1. Excellent Async Exception Safety ✅

   • 1,249 ConfigureAwait(false) calls across 487 async methods
   • Consistent pattern in analyzers, code fixes, and platform services
   • Prevents deadlocks and context-switching issues

2. Sophisticated Exception Filtering ✅

   • 82 exception filters using catch (...) when (...) clauses
   • Excellent example in Assert.AreEquivalent.Comparer.cs:

     catch (Exception ex) when (ex is not OutOfMemoryException 
         and not StackOverflowException 
         and not UnitTestAssertException)

   • Prevents catching non-recoverable exceptions (OutOfMemoryException, StackOverflowException)

3. Strong nameof Usage ✅

   • 211 exceptions use nameof for parameter names
   • Refactoring-safe, compile-time checked parameter references

4. Advanced Exception Preservation ✅

   • 9 ExceptionDispatchInfo usages for preserving stack traces
   • AssertScope.cs properly aggregates multiple assertion failures
   • Correct use of bare throw; (32 instances) vs throw ex; (only 5)

5. Proper AggregateException Handling ✅

   • 42 AggregateException usages, primarily in TestResult.cs and AssertScope.cs
   • Correctly aggregates multiple assertion failures for scope-based assertions

Areas for Improvement

1. Zero Modern Null Validation Adoption ❌ HIGH PRIORITY

   • 181 ArgumentNullException throws but 0 uses of ArgumentNullException.ThrowIfNull
   • .NET 6+ provides ArgumentNullException.ThrowIfNull(arg) helper
   • Repository targets .NET 8, should leverage modern patterns
   • Current pattern requires manual null checks + throw statements

2. Stack Trace Loss Anti-Pattern ⚠️ HIGH PRIORITY

   • 5 instances of throw ex; in production code:
     • src/Adapter/MSTestAdapter.PlatformServices/Execution/ClassCleanupManager.cs:70
     • src/Adapter/MSTestAdapter.PlatformServices/Execution/ClassCleanupManager.cs:86
   • Should use bare throw; to preserve stack traces
   • Affects debugging and error diagnosis

3. Async Void Methods (Unhandled Exception Risk) ⚠️ MEDIUM PRIORITY

   • 50 async void methods in codebase
   • Unhandled exceptions in async void methods crash the process
   • Most are in test code (with VSTHRD100 suppressions), but requires audit
   • Best practice: async Task methods with proper exception handling

4. Incomplete Custom Exception Design ⚠️ MEDIUM PRIORITY

   • AdapterSettingsException.cs: Missing parameterless constructor, innerException constructor
   • Several custom exceptions lack standard constructor overloads
   • Pattern inconsistency: TypeInspectionException has full constructors, others don't
   • Impacts exception propagation and serialization scenarios

5. Hardcoded Exception Messages ⚠️ MEDIUM PRIORITY

   • 199 hardcoded vs 121 localized exception messages (62% hardcoded)
   • Violates localization guidelines for user-facing errors
   • Examples found across test infrastructure and platform services
   • Should use resource strings for consistent localization

6. Limited Exception Documentation ⚠️ LOW PRIORITY

   • Only 159 <exception> XML documentation tags across 2,919 files
   • Public API methods often lack exception documentation
   • Makes it harder for consumers to understand error conditions

7. Exception-Related Technical Debt ⚠️ LOW PRIORITY

   • 6 TODOs related to exception handling:
     • TestExecutionContext.cs: "Filter exceptions that are to be considered as failures"
     • TestDataSource.cs: "Change exception type to more specific one (Repository Quality: Analyzer Catalog Hygiene Improvements #8086)"
     • MethodInfoExtensions.cs: "Better to throw? or tolerate?"
   • Some tracked by issue Repository Quality: Analyzer Catalog Hygiene Improvements #8086, others untracked

---

🤖 Suggested Improvement Tasks

The following actionable tasks address the findings above, prioritized by impact and effort.

Task 1: Adopt ArgumentNullException.ThrowIfNull for Null Validation

Priority: High
Estimated Effort: Medium
Impact: Modernization, code consistency, reduced boilerplate

Description:

Replace traditional null-check patterns with the modern .NET 6+ ArgumentNullException.ThrowIfNull helper across the codebase.

Current Pattern (181 occurrences):

if (parameter is null)
{
    throw new ArgumentNullException(nameof(parameter));
}

Modern Pattern:

ArgumentNullException.ThrowIfNull(parameter);

Benefits:

• Single-line null validation
• Consistent with modern .NET idioms
• Reduces boilerplate by ~3 lines per validation
• Compile-time safety with nameof embedded in helper

Target Files: All files throwing ArgumentNullException (181 instances found)

Acceptance Criteria:

• Replace at least 80% of traditional null checks with ThrowIfNull
• Update coding guidelines to mandate ThrowIfNull for new code
• Add analyzer rule (if not present) to suggest ThrowIfNull

---

Task 2: Fix Stack Trace Loss Anti-Pattern in ClassCleanupManager

Priority: High
Estimated Effort: Small
Impact: Debugging, production diagnostics

Description:

Fix the 5 instances of throw ex; anti-pattern that lose original stack traces. This primarily affects ClassCleanupManager.cs which handles test class cleanup exceptions.

Affected Files:

• src/Adapter/MSTestAdapter.PlatformServices/Execution/ClassCleanupManager.cs (lines 70, 86)

Current Anti-Pattern:

catch (Exception ex)
{
    // ... processing ...
    throw ex; // ❌ Loses original stack trace
}

Correct Pattern:

catch (Exception ex)
{
    // ... processing ...
    throw; // ✅ Preserves original stack trace
}

Impact: When test cleanup methods throw exceptions, stack traces currently reset to the rethrow point, obscuring the original failure location.

Acceptance Criteria:

• Replace all 5 throw ex; instances with bare throw;
• Verify stack traces preserve original exception location in test scenarios
• Add analyzer suppression or comment if intentional (unlikely)

---

Task 3: Audit and Eliminate Async Void Methods

Priority: Medium
Estimated Effort: Medium
Impact: Reliability, testability, exception handling

Description:

Audit the 50 async void methods in the codebase and convert to async Task where possible. Async void methods have unhandled exception semantics that crash the process, making them unsuitable outside event handlers.

Current State:

• 50 async void methods detected
• Most appear to be in test code with VSTHRD100 suppressions
• Some may be intentional (e.g., event handlers, UI callbacks)

Conversion Pattern:

// Before
public async void ProcessAsync()
{
    await DoWorkAsync();
}

// After
public async Task ProcessAsync()
{
    await DoWorkAsync();
}

Tasks:

1. Identify all 50 async void methods
2. Categorize: event handlers (keep) vs regular methods (convert)
3. Convert non-event-handler methods to async Task
4. For legitimate event handlers, add try-catch with logging
5. Update callers to await Task-returning methods

Acceptance Criteria:

• Document all async void methods and justify retention
• Convert non-event-handler async void to async Task
• Add exception handling to remaining async void event handlers
• Update VSTHRD100 suppressions with justification comments

---

Task 4: Standardize Custom Exception Constructors

Priority: Medium
Estimated Effort: Small
Impact: API consistency, serialization, exception propagation

Description:

Add standard exception constructor overloads to custom exception types following the .NET exception design guidelines. Several custom exceptions (AdapterSettingsException, TestFailedException, etc.) lack the recommended constructors.

Standard Exception Pattern:

public class CustomException : Exception
{
    public CustomException() { }
    
    public CustomException(string message) 
        : base(message) { }
    
    public CustomException(string message, Exception innerException) 
        : base(message, innerException) { }
}

Affected Custom Exceptions:

• AdapterSettingsException.cs — Missing parameterless and innerException constructors
• TestFailedException.cs — Missing constructors
• InvalidManagedNameException.cs — Missing constructors
• MSTestException.cs — Verify constructor completeness

Acceptance Criteria:

• All custom exceptions have 3 standard constructors
• Serialization constructors present where needed (check .NET 8 requirements)
• XML documentation on all custom exception classes
• Unit tests verify constructor behavior

---

Task 5: Reduce Hardcoded Exception Messages via Localization

Priority: Medium
Estimated Effort: Large
Impact: Localization, user experience, message consistency

Description:

Reduce the 199 hardcoded exception messages by moving them to resource strings. Currently 62% of exception messages are hardcoded, violating the repository's localization guidelines.

Current Pattern (199 occurrences):

throw new InvalidOperationException("The test context is not available.");

Localized Pattern (121 occurrences):

throw new InvalidOperationException(Resources.TestContextNotAvailable);

Approach:

1. Audit the 199 hardcoded messages
2. Identify user-facing vs internal/debug messages
3. Add resource entries for user-facing messages
4. Update exception throw sites to use resources
5. Run dotnet msbuild <project>.csproj /t:UpdateXlf to regenerate .xlf files

Target Areas:

• TestFramework user-facing exceptions (high priority)
• Platform services adapter exceptions (medium priority)
• Internal exceptions can remain hardcoded if never user-visible

Acceptance Criteria:

• Reduce hardcoded rate from 62% to <40%
• All public API exceptions use localized resources
• Update .xlf files with new resource strings
• Document which exceptions can remain hardcoded (internal-only)

---

📊 Historical Context

Previous Focus Areas

Date	Focus Area	Type
2026-04-30	MSTest Analyzer Ecosystem Health	Custom
2026-05-01	Technical Debt Comment Hygiene	Custom
2026-05-05	Warning Suppression Debt & Diagnostic Hygiene	Custom
2026-05-21	Exception Handling & Error Recovery Patterns	Custom

Statistics:

• Total quality improvement runs: 4
• Custom focus area rate: 100%
• Unique areas explored: 4

---

🎯 Recommendations

Immediate Actions (This Week)

1. Fix throw ex; Anti-Pattern — Priority: High

   • 5 instances in ClassCleanupManager.cs
   • Simple search-replace fix
   • Immediate debugging improvement

2. Begin ArgumentNullException.ThrowIfNull Migration — Priority: High

   • Start with high-traffic public APIs
   • Update coding guidelines document
   • Add to PR review checklist

Short-term Actions (This Month)

1. Audit Async Void Methods — Priority: Medium

   • Categorize all 50 instances
   • Convert non-event-handlers to async Task
   • Document legitimate async void usage

2. Standardize Custom Exception Constructors — Priority: Medium

   • Quick wins on 4-5 custom exception types
   • Improves API consistency
   • Enables better exception propagation

3. Begin Exception Message Localization — Priority: Medium

   • Start with TestFramework public APIs
   • Document localization policy for new code
   • Reduce hardcoded rate incrementally

---

Generated by Repository Quality Improvement Agent
Next analysis: 2026-05-22 — Focus area selected based on diversity algorithm

Generated by Repository Quality Improver · ● 3.7M · ◷

• expires on May 23, 2026, 10:57 PM UTC

[Evangelink]

Quick correction on Task 2 (Fix Stack Trace Loss Anti-Pattern in ClassCleanupManager) — the two throw ex; instances flagged in ClassCleanupManager.cs (lines 70 and 86) are not the classic throw ex; anti-pattern, and changing them to throw; would not compile.

Why it''s a false positive

The anti-pattern (CA2200 "Rethrow to preserve stack details") specifically applies when re-throwing an exception that was caught in a catch block, because doing so resets the stack trace. Neither flagged site is inside a catch. The code is:

TestFailedException? ex = classInfo.ExecuteClassCleanupAsync(testContext).GetAwaiter().GetResult();
if (ex is not null)
{
    throw ex;
}

Here ex is a TestFailedException? returned as a value by TestClassInfo.ExecuteClassCleanupAsync / TestAssemblyInfo.ExecuteAssemblyCleanupAsync (see TestClassInfo.cs:635-648 and TestAssemblyInfo.cs:322-332 — the exception is constructed via new TestFailedException(...) and returned, never thrown). Because the exception has never been thrown before, there is no original stack trace to preserve.

• throw; is a compile error here — no ambient exception context.
• ExceptionDispatchInfo.Capture(ex).Throw() would add nothing — there is no prior stack trace to capture, and the underlying failure is already preserved via InnerException (realException).
• throw ex; is the correct and only valid syntax, and it sets the stack trace at this call site, which is exactly what we want.

This is consistent with the fact that CA2200 does not flag these lines and there is no suppression for it anywhere in the repo (the analyzer correctly understands this is not the anti-pattern).

Suggestion for the analyzer

The detection heuristic for Task 2 should require that the throw ex; statement be lexically inside a catch clause whose exception variable matches ex. As written, it produces false positives for any pattern where a method returns an exception as a value and the caller throws it (a legitimate and common .NET pattern — e.g., Task<Exception?>-returning runners).

Marking Task 2 as not actionable / false positive. The other findings in this report (ArgumentNullException.ThrowIfNull adoption, async void audit, localization, etc.) still stand on their own merits.

[Evangelink]

Confirming: Task 1 (Adopt ArgumentNullException.ThrowIfNull) cannot be implemented as a blanket replacement because the shipping libraries multi-target frameworks that do not have that helper.

TFM matrix

ArgumentNullException.ThrowIfNull was introduced in .NET 6. The repo''s production projects target a much wider set (Directory.Build.props defines <SupportedNetFrameworks>net8.0;net9.0</SupportedNetFrameworks>, plus NetFrameworkMinimum = net462, UwpMinimum = uap10.0.16299, and netstandard2.0):

Project	TargetFrameworks
Microsoft.Testing.Platform	net8.0;net9.0;netstandard2.0
MSTest.TestAdapter	net462;net8.0;net9.0;uap10.0.16299;net8.0-windows...;net9.0-windows...
MSTestAdapter.PlatformServices	same as above
TestFramework	netstandard2.0;net462;net8.0;net9.0
TestFramework.Extensions	netstandard2.0;net462;net8.0;net9.0;uap10.0.16299;...
MSTest.Analyzers	netstandard2.0

ArgumentNullException.ThrowIfNull is not available on netstandard2.0, net462, or uap10.0.16299, which covers most of these libraries — including the analyzer project that targets netstandard2.0 only.

Why it''s a blocker today

A grep for ThrowIfNull in src/ returns zero hits — there is no internal polyfill/shim in the codebase. Adopting the helper would therefore require either:

1. Wrapping every call in #if NET6_0_OR_GREATER / #if NET — which negates the "less boilerplate" benefit Task 1 is trying to achieve, and produces inconsistent code paths that are harder to read.
2. Adding an internal ThrowIfNull polyfill (e.g., a ThrowHelper.ThrowIfNull or a [CompilerServices] extension method available on all TFMs). This is feasible but is itself a separate design decision (extra surface area, namespace pollution, behavior parity with the BCL helper for edge cases like CallerArgumentExpression, etc.) and is not what Task 1 proposes.

Until/unless we land such a shim, the current if (x is null) throw new ArgumentNullException(nameof(x)); pattern is the only consistent option that works on every TFM we ship.

Suggestion

Mark Task 1 as blocked / not actionable as-stated. If we want to revisit, it should be reframed as: "Introduce an internal ThrowIfNull polyfill so that we can adopt the modern pattern uniformly across all TFMs" — that is a distinct decision worth its own discussion/issue.

[Evangelink]

Reviewing Task 3 (Audit and Eliminate Async Void Methods) — the "50 async void methods" headline metric is misleading and the task is largely not actionable. The raw async void token count was not filtered for context, so it conflates real method declarations with comments, analyzer-fixture string literals, and acceptance-test source-code templates.

Breakdown of the ~51 raw hits

I re-ran the grep (\basync\s+void\b, *.cs, repo-wide) and categorized every hit:

Category	Hits	Real async void methods?
Analyzer test inputs (string literals containing {|#0:...|} / [|...|] Roslyn-test markers)	37	❌ No — they''re inputs to verify that our analyzers flag async void
Acceptance-test source template inside a raw string ("""...""" → PatchTargetFrameworks → TestAsset.GenerateAssetAsync)	1	❌ No — emitted into a generated test asset
Code comments (e.g. // We don''t support async void)	4	❌ No
Real async void method declarations in test fixtures	4	✅ Yes — all in test/
Real async void in src/ (production code)	0	✅ Verified via ^\s*[\w\s]*\basync\s+void\s+\w over src/ → no matches

So the production codebase has zero async void methods. The four real declarations are all in test code, in fixtures specifically designed to verify that the framework correctly handles user-authored async void:

• test/UnitTests/MSTestAdapter.PlatformServices.UnitTests/Extensions/MethodInfoExtensionsTests.cs:502, 509, 532 — PublicStaticAsyncVoidMethodWithTC, PublicStaticAsyncVoidMethod, PublicAsyncVoidMethod
• test/UnitTests/MSTestAdapter.PlatformServices.UnitTests/Discovery/TestMethodValidatorTests.cs:214 — AsyncMethodWithVoidReturnType

Every one of them carries [SuppressMessage("Usage", "VSTHRD100:Avoid async void methods", Justification = "Done on purpose")]. Removing them would defeat the test — they exist precisely to exercise the async-void code path in TypeInspectionHelper / MethodInfoExtensions / TestMethodValidator.

What the repo already does about user async void

The remaining 37 "hits" are not technical debt — they are test inputs for the analyzers we ship to detect this exact problem in customers'' code:

• AvoidUsingAssertsInAsyncVoidContextAnalyzer (MSTEST0039) + its codefix — see src/Analyzers/MSTest.Analyzers/AvoidUsingAssertsInAsyncVoidContextAnalyzer.cs
• TestMethodShouldBeValidAnalyzer, TestInitializeShouldBeValidAnalyzer, TestCleanupShouldBeValidAnalyzer, ClassInitializeShouldBeValidAnalyzer, ClassCleanupShouldBeValidAnalyzer, AssemblyInitializeShouldBeValidAnalyzer, AssemblyCleanupShouldBeValidAnalyzer, GlobalTestFixtureShouldBeValidAnalyzer — all reject async void fixture/test methods.
• MSTest.SourceGeneration/Helpers/TestMethods.cs:49 explicitly bails out on methodSymbol.ReturnsVoid && methodSymbol.IsAsync (// We don''t support async void).

Suggestion

Mark Task 3 as not actionable as stated. There is nothing to convert: the production code has zero async void methods, and the test-fixture ones are intentional with proper suppressions. If the agent wants to surface a real signal here, the detection rule should:

1. Parse async void as a Roslyn MethodDeclarationSyntax / LocalFunctionStatementSyntax with ReturnType == void and Modifiers containing async, not match the bare regex.
2. Exclude nodes inside string literals (LiteralExpressionSyntax/InterpolatedStringExpressionSyntax).
3. Exclude declarations carrying [SuppressMessage("Usage", "VSTHRD100", …)].

With those filters, the count for this repo would be 0 in src/, 0 unsuppressed in test/, and the task would correctly not be generated in the first place.

[Evangelink]

Reviewing Task 4 (Standardize Custom Exception Constructors) — this task is based on a misapplication of the .NET design guideline. The "3-ctor pattern" (parameterless / string message / string message, Exception innerException) is recommended for public, non-sealed exception types where consumers may catch by base type, instantiate themselves, or derive subclasses. All four flagged exceptions are internal sealed and their constructor sets are intentionally aligned with actual usage. Adding the missing overloads would create dead code that analyzers like IDE0290/RCS would flag as unused.

Per-type assessment

1. AdapterSettingsException (ObjectModel/AdapterSettingsException.cs)

• Declaration: internal sealed class AdapterSettingsException : Exception
• Constructors: (string? message) only.
• Call sites (7 total, all in MSTestSettings.Parallelize.cs / MSTestSettings.Configuration.cs): every single throw uses new AdapterSettingsException(string.Format(..., Resource.X, ...)) — message-only.
• Caught once (MSTestDiscovererHelpers.cs:36) and re-logged.
• Verdict: No need for parameterless or (string, Exception) ctors — no call site would use them. Internal sealed + single concrete usage shape = current design is correct. ❌ Claim incorrect.

2. TestFailedException (ObjectModel/TestFailedException.cs)

• Declaration: internal sealed [Serializable]
• Constructors: four overloads, all requiring a UnitTestOutcome plus a message:
  • (UnitTestOutcome, string)
  • (UnitTestOutcome, string, StackTraceInformation?)
  • (UnitTestOutcome, string, Exception?)
  • (UnitTestOutcome, string, StackTraceInformation?, Exception?)
• UnitTestOutcome is mandatory by design — a test-failed exception without an outcome makes no semantic sense.
• Verdict: Adding () / (string) / (string, Exception) would either need a meaningless default outcome or be silently wrong. The current overload matrix (4 combinations of optional StackTraceInformation × optional Exception) is complete. ❌ Claim incorrect — nothing is "missing".

3. InvalidManagedNameException (Helpers/InvalidManagedNameException.cs)

• Declaration: internal sealed class InvalidManagedNameException : Exception (no explicit ctors → implicit parameterless inherited from Exception).
• Call sites (13 total, all in ManagedNameParser.cs / ManagedNameHelper.cs): every single throw is parameterless — throw new InvalidManagedNameException();.
• Caught once (TypeCache.cs:712) as catch (InvalidManagedNameException) without ever inspecting the message.
• Verdict: The exception is a pure signal type. Adding (string) / (string, Exception) would be unused. ❌ Claim is dead-code in disguise.

4. MSTestException (Exceptions/MSTestException.cs)

• Declaration: internal sealed [Serializable]
• Constructors: (), (string msg), (string msg, Exception ex), and (SerializationInfo, StreamingContext) (with the proper [Obsolete(..., DiagnosticId = "SYSLIB0051")] guard for .NET 8+).
• Verdict: Already complete — this is in fact the gold-standard implementation in the codebase, including legacy BinaryFormatter serialization support for VS UI-testing scenarios (per the in-source comment). ✅ Claim incorrect — nothing to verify, it''s the most thorough custom exception we have.

Why the guideline doesn''t apply here

The .NET exception-design guideline assumes:

1. The type is public → external consumers may instantiate it with various overloads.
2. The type is not sealed → subclasses inherit constructor obligations.
3. The type may be serialized across BinaryFormatter boundaries → needs the SerializationInfo ctor.

For internal sealed exceptions used at known call sites:

• (1) doesn''t apply — only the assembly itself constructs them.
• (2) doesn''t apply — no subclasses possible.
• (3) only matters when crossing serialization boundaries (the MSTestException case, already covered).

Adding the overloads anyway costs us:

• Extra XML doc to maintain.
• Larger PublicAPI / surface to keep stable (even if internal, the type tracker still notices).
• Potential analyzer noise (e.g., S3925/CA1032 false reassurance vs IDE0290 unused-member for the new ctors).

Suggestion

Mark Task 4 as not actionable:

• 1 of 4 (MSTestException) is already complete — false positive on the "verify" line item.
• 3 of 4 are internal sealed with constructor sets perfectly matching their call sites; adding ctors would be dead code.

If the agent wants a real signal for this category, the heuristic should restrict to public, non-sealed exception types, and additionally check that the missing constructor would actually be used (no point adding a (string, Exception) when no call site wraps an inner exception).

[Evangelink]

Closing — after review, the actionable findings in this automated report did not hold up:

• Task 1 (ArgumentNullException.ThrowIfNull) — blocked by multi-targeting (netstandard2.0/net462/uap10.0.16299) and no polyfill exists; would require either #if wrappers (defeats the purpose) or introducing a shim (separate decision).
• Task 2 (throw ex; in ClassCleanupManager) — false positive; both sites throw a TestFailedException? returned as a value, not caught in a catch block. throw; would not compile, and there is no prior stack trace to preserve.
• Task 3 (async void audit) — src/ has 0 async void methods; the 4 real ones in test/ are intentional fixtures with explicit VSTHRD100 suppressions. The remaining ~47 raw hits are analyzer-test string literals, raw-string acceptance-test templates, or comments.
• Task 4 (custom exception constructors) — all four flagged types are internal sealed with constructor sets matching actual call-site usage; the 3-ctor guideline targets public, non-sealed types. MSTestException is already complete (including the SYSLIB0051-guarded serialization ctor).

Tasks 5 (localization) and 6 (xmldoc) are not refuted but are low-priority maintenance and don't warrant a tracking issue. The detection heuristics that produced these findings should be tightened (Roslyn syntax instead of regex, exclude string literals, respect access modifiers and suppressions) before re-running.