据我所知，在C#中没有办法执行检查异常。该语言不支持该功能（或者说是一个bug，取决于您如何看待它：）。
最好的办法是在方法中添加XML注解，包括方法抛出的异常，并希望调用代码的人阅读文档。
大概是这样的

/// <summary>
/// This is my method that does stuff.
/// </summary>
/// <exception cref="InvalidOperationException">This stuff can't be done!</exception>
public void DoStuff() 
{
    // do stuff
}

我打赌你可以使用像PostSharp这样的工具来实现检查异常。

[Throws(typeof(MyExpection))]
public void Method()
{
   throw new MyException();
}

不确定类似的东西是否已经存在于PostSharp或其他AOP框架中（.NET的设计者不喜欢检查异常的原因仍然成立），但我打赌这是可能的。

向中华问：“是否有办法在Visual Studio中模拟（可能通过样式操作？）或打开检查的异常？”-是：请尝试以下Visual Studio扩展：https://marketplace.visualstudio.com/items?itemName=YoavFrandzel.CheckedExceptions

检查异常被包含在Java中是因为一个错误的想法，即方法的调用者必须了解被调用方法可能失败的所有方式。现在这个想法是错误的。因此，检查异常是一个有害的遗留概念，应该避免。
检查异常的原始Java原理是修复脆弱的C风格处理错误的方式。C通过返回一个特殊值来指示错误，如-1、NULL或NaN。必须手动检查该返回值，否则错误将被忽略。由于检查是冗长乏味的，C程序员经常忽略它，从而导致失败。
检查异常是一种误导的方法，它迫使程序员“检查返回值”。Java设计者当时没有完全理解的是，对于异常，没有必要“检查返回值”。在没有处理程序的情况下，异常不会被忽略。C的返回值会被忽略。
此外，异常不是方法公共接口的一部分。它们是实现细节，可能会发生变化。例如，一个方法：

BigInteger fibonacci(BigInteger n)

可能会通过计算返回一个较大的Fibonacci数。在某个时候，该方法的实现可能会被优化为从缓存文件中读取较大的数字。突然，该方法可能会引发大量以前不存在的新I/O异常！
调用代码不能也不应该知道一个方法可能抛出什么异常。调用代码应该假设一个方法可以抛出 * 任何异常 *。
幸运的是，这样的假设并不意味着调用方法的代码一定很复杂。在绝大多数情况下，处理异常的正确方法是让它在堆栈中向上传播。并非偶然，这是程序员什么都不做时的默认行为，这也是异常管理错误的优雅和简洁的方式。