当前位置：文江博客话题详情

C# 检查异常

发布于 2024-08-26 23:22:03 字数 250 浏览 4 评论 0原文

我非常喜欢 Java 中但 C# 中没有的一项功能，那就是检查异常。有什么方法可以在 Visual Studio 中模拟（也许通过 stylecop？）或打开检查异常？

是的，我知道很多人不喜欢它们，但我发现它们很有帮助。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我的奇迹 2024-09-02 23:22:03

据我所知，C# 中没有办法执行检查异常。该语言不支持该功能（或错误，取决于您如何看待它:)）。

最好的选择是向您的方法添加 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
}

Far as I know, there's no way to do checked exceptions in C#. That feature (or a bug, depending on how you look at it :)) is not supported by the language.

Your best bet would be to add XML comments to your method, include the exceptions thrown by it and hope whoever calls your code reads the documentation.

Something like this:

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

回复收藏 0 原文

鸵鸟症 2024-09-02 23:22:03

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

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

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

I bet you could use a tool like PostSharp to implement checked exceptions. Something like:

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

Not sure if something like this already exists in PostSharp or some other AOP framework (and the reasons why the designers of .NET don't like checked exceptions still hold true) but I bet it would be possible to do.

回复收藏 0 原文

み青杉依旧 2024-09-02 23:22:03

对于这个问题：
“有什么方法可以在 Visual Studio 中模拟（也许通过 stylecop？）或打开检查异常？” - 是的：尝试这个 Visual Studio 扩展：https://marketplace.visualstudio.com/items ?itemName=YoavFrandzel.CheckedExceptions

回复收藏 0 原文

孤城病女 2024-09-02 23:22:03

Java 中包含了检查异常，因为有一个错误的想法，即方法的调用者必须了解被调用方法可能失败的所有方式。现在已知这个想法是错误的。因此，检查异常是一个有害的遗留概念，应该避免。

Java 中检查异常的最初原理是为了修复脆弱的 C 风格的错误处理方式。 C 通过返回特殊值（例如 -1、NULL 或 NaN）来指示错误。必须手动检查此返回值，否则错误将被忽略。由于检查繁琐且冗长，C 程序员经常忽略它，从而导致错误。

检查异常是一种强迫程序员“检查返回值”的误导性尝试。 Java 设计者当时没有完全理解的是，除了异常之外，不需要“检查返回值”。没有处理程序的异常不会被忽略。 C返回值确实如此。

此外，异常不是方法的公共接口的一部分。它们是实施细节，可能会发生变化。例如，一个方法：

BigInteger fibonacci(BigInteger n)

可能会通过计算返回一个大的斐波那契数。在某些时候，该方法的实现可能会被优化以从缓存文件中读取大量数据。突然间，该方法可能会抛出大量以前不存在的新 I/O 异常！

调用代码不能也不应该知道方法可能抛出什么异常。调用代码应该假设方法可以抛出任何异常。

幸运的是，这样的假设并不意味着调用方法的代码一定很复杂。在绝大多数情况下，处理异常的正确方法是让它在堆栈中向上传播。并非偶然，这是程序员不执行任何操作时的默认行为，这就是使异常成为管理错误的优雅而简洁的方式的原因。

Checked exceptions were included in Java because of the fallacious idea that caller of a method must understand all the ways the called method can possibly fail. This idea is now known to be wrong. As such, checked exceptions are a harmful legacy concept, and should be avoided.

The original Java rationale for checked exceptions was to fix the fragile C-style way of dealing with errors. C indicated an error by returning a special value, such as -1, NULL or NaN. This return value had to be be manually checked, otherwise the error would get ignored. Because the checking was tedious and verbose, it was frequently omitted by C programmers, leading to bugs.

Checked exceptions were a misguided attempt to force the programmer to "check the return value". What Java designers did not fully understand at the time, is that with exceptions there is no need to "check the return value". An exception in absence of a handler does not get ignored. C return value does.

Moreover, exceptions are not part of the public interface of a method. They are an implementation detail, subject to change. For example, a method:

BigInteger fibonacci(BigInteger n)

might return a large Fibonacci number by calculating it. At some point, the implementation of the method might be optimized to read large numbers from a cache file instead. Suddenly, a plethora of new I/O exceptions can be thrown by the method, that were not present before!

The calling code can not, and should not know what exceptions might possibly be thrown by a method. The calling code should assume a method can throw any exception whatsoever.

Fortunately, such assumption does not mean the code of the calling method must be complicated. In an overwhelming majority of cases, the correct way to deal with an exception is to let it propagate up the stack. Not incidentally, this is the default behavior when programmer does nothing, and this is what makes exceptions such an elegant and terse way to manage errors.

回复收藏 0 原文

~没有更多了~