C#明确定义了抛出的异常

And*_*Hin 26 c# interface exception

在Java中,您使用"throws"关键字明确定义了抛出的异常.这样,任何调用你的方法的人都知道要抓到什么.

C#中有什么东西吗?如果没有,我如何知道要捕获的异常,或者如何让其他人知道要捕获哪些异常?

另外,如果我正在定义一个接口,有没有办法说"methodX()应该在出错时抛出此异常"?

Mit*_*eat 34

在C#中没有任何等价物:Checked Exceptions的麻烦

除了文档之外,没有办法声明接口说"methodX()应该在出错时抛出此异常".

  • @dbkk:他的反对意见大部分是谬误的.例如,他抱怨说你不能在不改变API的情况下在实现中抛出新类型的异常,因此旧的客户端代码无法调用它.这是事实,但是可取的.如果抛出新的异常,则API已更改是否在其中明确指定了异常.就个人而言,一旦尝试使用API​​,我宁愿让客户端断断续续地破坏,而不是以微妙的方式进一步失败,这要归功于我没有处理所有异常. (4认同)
  • @Ian Ringrose:正确处理错误条件被证明可以减少错误.事实证明,定义明确的API可以减少错误.忽略异常不是. (3认同)
  • @JeramyP,但你应该编写你的代码来检查操作是否有效**之前**,所以异常不应该是常见的. (2认同)

Ian*_*ose 12

C#/ .net没有检查异常,事实证明它们在大规模系统中的用处不如首先想象的那么多.在很多项目中,维护检查异常规范的时间远远大于通过使用它们节省的调试时间.

Checked Exceptions似乎是一个很好的理想,直到你有方法可以将委托或调用带入你传入的对象.举一个简单的例子,列表上的Sort()方法不知道它会抛出什么异常,因为它不会知道正在排序的对象的Compar()方法会抛出什么异常.

因此,方法可能抛出的异常的规范必须能够包含有关如何通过对象和委托传递异常的信息. 没人知道怎么做!

但是,有一些工具可以检查是否捕获了所有异常 - 请参阅Red Gate的异常猎人.我个人认为这些工具没有太多价值,但是如果你喜欢检查过的例外,你会发现它们很有用.


Liv*_* M. 8

此功能在C#中不可用.您可以制作正确的XML文档(3个斜杠///)并说明抛出的异常.

这将由IntelliSense机制获取,并且在使用它之前将对类/方法的用户可见.