The long and the short answer is that this isn't possible. Unlike Java, none of the .NET languages require that functions report a list of possible exceptions that can be thrown (which means that you either have to catch or report any exceptions that could be thrown on functions that it calls). Because of this, there's no generic way to determine an exhaustive list of every exception that a function could throw (I'm using the word function here to cover anything that's written like a function, including operators, constructors, etc.) because you have no guarantee as to the exceptions that could be thrown by what a given function might call.
If you're willing to go in limited, then it's conceivable that you could write something that could scan MSDN for the appropriate article for a given .NET library call and use the list of exceptions there (if any) to recursively establish a list of what could possibly be thrown. This wouldn't, however, cover any third-party libraries or catch any exceptions thrown by the runtime (OutOfMemoryException, StackOverflowException, NullReferenceException [unless you want to take it a step further and have your exception analysis also determine if there is any possibility of a null reference, but this, too, seems impossible to do in a completely generic sense]).
I'm pretty sure that this has been covered a time or two by the C# team (I'd be surprised if Eric Lippert hasn't already answered a question about this on SO), but I'm pretty certain that it boiled down to this: While this sort of system is useful and valuable to some people, mandating its use (and forcing you either to report or catch all possibly thrown exceptions) led to a lot of try { ... } catch (Exception ex) { ... } blocks in order to avoid the housekeeping, and blanket, silent catches are a lot worse (IMHO) than an unreported exception.
Exception Hunter from RedGate software will get you half-way there. It can do a static analysis of your code and show you what exceptions will be thrown by what lines of code -- including .NET Framework calls. It won't write the XML documentation for you.
But, I have to say, you need to be realistic about how useful such a tool would be... there are a number of exceptions that may happen as a result of extremely unusual circumstances, such as System.OutOfMemoryException and System.ExecutionEngineException, or as a result of programmer error, such as System.NotImplementedException. Technically, these are all possible, but realistically, attempting to document most of them for every method is not worth your time... you'd end up with hundreds of lines of comment for practically every method in your application.
发布评论
评论（4）
长而短的答案是这是不可能的。与 Java 不同，.NET 语言都不要求函数报告可能引发的异常的列表（这意味着您必须捕获或报告其调用的函数可能引发的任何异常）。因此，没有通用的方法来确定函数可能抛出的每个异常的详尽列表（我在这里使用函数一词来涵盖像函数一样编写的任何内容，包括运算符、构造函数等），因为您无法保证给定函数可能调用的异常可能会引发。
如果您愿意进行限制，那么可以想象您可以编写一些内容来扫描 MSDN 以查找给定 .NET 库调用的相应文章，并使用那里的异常列表（如果有）递归地建立一个列表可能会抛出什么。但是，这不会覆盖任何第三方库或捕获运行时引发的任何异常（
OutOfMemoryException、StackOverflowException、NullReferenceException[除非您想更进一步，让异常分析也确定是否存在空引用的可能性，但这在完全通用的意义上似乎也是不可能的]）。我很确定 C# 团队已经对此进行过一两次讨论（如果 Eric Lippert 还没有回答有关此问题的问题，我会感到惊讶），但我很确定它归结为对此：虽然这种系统对某些人来说很有用且有价值，但强制使用它（并强制您报告或捕获所有可能抛出的异常）会导致大量
try { ... } catch (Exception ex) { ... }块以避免内务处理，而一揽子、无声的捕获比未报告的异常要糟糕得多（恕我直言）。The long and the short answer is that this isn't possible. Unlike Java, none of the .NET languages require that functions report a list of possible exceptions that can be thrown (which means that you either have to catch or report any exceptions that could be thrown on functions that it calls). Because of this, there's no generic way to determine an exhaustive list of every exception that a function could throw (I'm using the word function here to cover anything that's written like a function, including operators, constructors, etc.) because you have no guarantee as to the exceptions that could be thrown by what a given function might call.
If you're willing to go in limited, then it's conceivable that you could write something that could scan MSDN for the appropriate article for a given .NET library call and use the list of exceptions there (if any) to recursively establish a list of what could possibly be thrown. This wouldn't, however, cover any third-party libraries or catch any exceptions thrown by the runtime (
OutOfMemoryException,StackOverflowException,NullReferenceException[unless you want to take it a step further and have your exception analysis also determine if there is any possibility of a null reference, but this, too, seems impossible to do in a completely generic sense]).I'm pretty sure that this has been covered a time or two by the C# team (I'd be surprised if Eric Lippert hasn't already answered a question about this on SO), but I'm pretty certain that it boiled down to this: While this sort of system is useful and valuable to some people, mandating its use (and forcing you either to report or catch all possibly thrown exceptions) led to a lot of
try { ... } catch (Exception ex) { ... }blocks in order to avoid the housekeeping, and blanket, silent catches are a lot worse (IMHO) than an unreported exception.您可以使用支持记录异常的 AtomineerUtils 来实现部分要求。
您还可以使用 GhostDoc、Resharper 和 Agent Johnson 插件，用于生成异常。请参阅以下问题：
如何记录 c#/.net 中抛出的异常
You can achieve part of your requirements by using AtomineerUtils which has support for documenting exceptions.
You can also use GhostDoc, Resharper and Agent Johnson Plugin for generating exceptions. See the following question:
How to document thrown exceptions in c#/.net
RedGate 软件的Exception Hunter 将帮助您成功一半。它可以对您的代码进行静态分析，并向您显示哪些代码行将引发哪些异常 - 包括 .NET Framework 调用。它不会为您编写 XML 文档。
但是，我不得不说，您需要现实地认识到这样的工具有多么有用...由于极其不寻常的情况，可能会发生许多异常，例如 System.OutOfMemoryException code> 和 System.ExecutionEngineException，或者由于程序员错误而导致，例如
System.NotImplementedException。从技术上讲，这些都是可能的，但实际上，尝试为每种方法记录其中的大部分内容并不值得您花时间......您最终会为应用程序中的几乎每种方法提供数百行注释。Exception Hunter from RedGate software will get you half-way there. It can do a static analysis of your code and show you what exceptions will be thrown by what lines of code -- including .NET Framework calls. It won't write the XML documentation for you.
But, I have to say, you need to be realistic about how useful such a tool would be... there are a number of exceptions that may happen as a result of extremely unusual circumstances, such as
System.OutOfMemoryExceptionandSystem.ExecutionEngineException, or as a result of programmer error, such asSystem.NotImplementedException. Technically, these are all possible, but realistically, attempting to document most of them for every method is not worth your time... you'd end up with hundreds of lines of comment for practically every method in your application.RedGate Exception Hunter 会分析代码中可能出现的异常。也许您可以使用它的一些功能。
RedGate Exception Hunter does analyze code for possible exception. Maybe you could use some of its functionality.