为何使用Activator.CreateInstance时无法捕获构造函数的ArgumentNullException？

这个问题和跨线程执行、调试器设置都没有关系，是.NET 反射调用的固定异常包装机制导致的：

• 直接执行new TestClass(null)时，构造函数抛出的ArgumentNullException会按原类型直接向上冒泡，所以Assert.Throws<ArgumentNullException>可以正常匹配异常类型，测试顺利通过。
• 但通过Activator.CreateInstance调用构造函数时，运行时不会把构造函数内部抛出的异常直接向外抛，而是会把所有构造函数执行过程中产生的异常，统一包裹在System.Reflection.TargetInvocationException类型的异常对象中，原始异常会被保存在这个外层异常的InnerException属性里。

你代码中写的catch (ArgumentNullException)只会匹配类型完全一致的异常，根本接不住外层抛出的TargetInvocationException，所以catch块永远不会被触发，异常会直接冒泡到测试框架，最终导致测试失败。

调试器在构造函数位置中断、提示异常未处理，是因为调试器默认开启了「第一次异常抛出时断入」的功能——哪怕这个异常最终会被反射层包装、正常向上传播，调试器也会先在原始抛出的位置打断给你看，这并不是真的没有代码处理这个异常。

• 针对当前测试场景，调整catch的匹配逻辑，接住外层的包装异常，再通过异常过滤器判断内部的真实异常类型即可，示例代码：

try
{
    testInstance = (TestClass)Activator.CreateInstance(typeof(TestClass), (string)null);
    Assert.Fail("Should not get here");
}
catch (TargetInvocationException ex) when (ex.InnerException is ArgumentNullException)
{
    // 此处会正常命中捕获逻辑
}

• 针对你提到的实际业务场景——遍历类校验是否存在指定参数的构造函数，其实根本不需要走到“实例化触发异常”的步骤：直接通过反射读取类型的构造函数元数据，判断是否存在匹配参数签名的构造函数即可，既高效又能完全避开反射异常包装的相关问题，示例：

// 判断目标类型是否存在接受单个string类型参数的公共构造函数
var ctor = typeof(TestClass).GetConstructor(new[] { typeof(string) });
// 如果返回null，就说明没有匹配的构造函数，可以提前记录问题

补充说明：这个异常包装机制是.NET从早期版本就有的固定设计，目的是把「反射调用本身的错误（比如找不到构造函数、参数类型不匹配）」和「被调用的目标代码自己抛出的业务异常」做区分，避免异常来源混淆。

内容的提问来源于stack exchange，提问作者PMF