feat: add option to require exact exception type in ExceptionParameterNameAssertion

[thomhurst]

Fixes #3665

[claude]

Claude finished @thomhurst's task —— View job

---

Code Review for PR #3672

Reviewing "feat: add option to require exact exception type in ExceptionParameterNameAssertion"

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze main implementation changes in ExceptionPropertyAssertions.cs
• Review changes in ThrowsAssertion.cs
• Check test modifications and coverage
• Verify public API snapshot updates are appropriate
• Provide comprehensive code review feedback

---

✅ Overall Assessment

This is a well-implemented and clean feature addition that properly addresses the need to differentiate between exact type matching and inheritance-based matching for exception parameter name assertions.

🔍 Detailed Review

✅ Code Quality & Best Practices

1. Excellent Design: The implementation properly distinguishes between Throws<T>() (allows subclasses) and ThrowsExactly<T>() (exact type only) by passing requireExactType: true only for the exact variant.

2. Backward Compatibility: The new requireExactType parameter has a sensible default of false, preserving existing behavior.

3. Clear Logic Flow: The exact type check is performed before the ArgumentException check, providing proper error precedence.

4. Good Error Messages: The error messages are descriptive and distinguish between exact type mismatches and parameter name mismatches.

✅ Implementation Correctness

1. Proper Type Checking: exception.GetType() != typeof(TException) correctly checks for exact type match (not inheritance-based).

2. Exception Handling: All edge cases are properly handled (null exceptions, evaluation exceptions).

3. Method Signatures: The changes maintain API consistency across both assertion types.

✅ Test Coverage

The test modifications in Throws.WithParameterNameTests.cs:14 properly update the expected message to include (exact type), confirming the feature works correctly with ThrowsExactly<T>().

✅ API Design

1. Consistent with Framework: The behavior aligns with TUnit's existing Throws/ThrowsExactly pattern.

2. Public API Changes: The snapshot updates correctly reflect the new optional parameter addition.

3. Expression Builder: Proper integration with the fluent API expression tracking.

✅ Performance Considerations

• Minimal performance impact: only adds a simple type comparison when requireExactType is true
• No allocations in hot paths
• Efficient early return on type mismatch

✅ Security & Safety

• No security concerns identified
• Type-safe implementation
• Proper null checking

🚀 Strengths

1. Clean Implementation: The feature is implemented with minimal code changes and maximum clarity
2. Excellent Integration: Seamlessly integrates with existing Throws/ThrowsExactly pattern
3. Proper Documentation: XML comments clearly explain the behavior
4. Comprehensive Testing: Test updates verify the new functionality
5. API Consistency: Maintains consistent behavior with TUnit's design patterns

📝 Minor Observations

1. Code Style: ✅ Follows TUnit's modern C# patterns and coding standards
2. Snapshot Updates: ✅ Properly updated all target framework snapshots
3. Error Messages: ✅ Clear and descriptive error messages that help developers debug issues

🎯 Final Verdict

This PR demonstrates excellent code quality and follows TUnit's development guidelines precisely. The feature is:

• ✅ Well-designed with proper separation of concerns
• ✅ Backward compatible with sensible defaults
• ✅ Thoroughly tested with appropriate test updates
• ✅ Performance-conscious with minimal overhead
• ✅ Properly documented with clear expectations

Recommendation: ✅ APPROVE - This is a high-quality implementation that adds valuable functionality while maintaining TUnit's standards.

---