我们正在为API编写一些全局异常处理程序,我们只需要在Debug配置中执行某些方法,显然有条件的方法是可行的解决方案。

但是我看到的是[Conditional("DEBUG")]只能用于返回类型为void的方法,如MSDN所说:


  有条件方法受以下限制:
  
  
  条件方法必须是类或结构中的方法
  宣言。如果Conditional属性发生编译时错误
  在接口声明中的方法上指定。
  条件方法的返回类型必须为void。
  条件方法不得使用override修饰符标记。但是,可以使用虚拟修饰符标记条件方法。此类方法的覆盖是隐式条件的,并且不得使用条件属性明确标记。
  条件方法不能是接口方法的实现。否则,将发生编译时错误。
  


资料来源:https://msdn.microsoft.com/en-us/library/aa664622(v=vs.71).aspx

我们知道标有ConditionalAttribute的方法到达了IL,为什么CLR不能简单地拦截例如返回default(T)的方法调用,因此允许具有任何类型的返回类型的方法是有条件的?还是我想念什么?

最佳答案

为什么不CLR只是截取返回default(T)的方法调用


更重要的是...为什么会这样?如果没有令人信服的理由这样做,那么就没有令人信服的理由投入大量精力,工时,成本等来进行辩论,设计,考虑所有可能的情况,进行开发,测试并继续进行下去。在所有将来的语言版本中都支持它。对于一开始就不需要的功能,这是相当可观的节省。

保证void方法没有结果。因此,已经存在逻辑上的保证,那就是没有任何东西可以依靠它的结果。返回值的方法无法提供此类保证。

由于没有任何东西依赖于它的结果,因此省略它不会改变代码/逻辑的直接本地行为。而如果某物确实依赖于其结果(或至少可能依赖于其结果),则局部行为可能会发生变化,这是不希望的。这种情况可能会带来许多意想不到的变化。即使是简单的返回null的代码,其中代码都不希望null

也许可以亲自坚持认为,自己可以考虑自己的逻辑并在编译器可以保证的范围之外做出自己的保证。 (并且类型转换和反射之类的东西对于该开发人员来说可能是有用的工具,条件是它们可以维持他们认为可以的稳定性。)但是在这种特殊情况下,很快就会成为开发代码和生产代码不再做的事情。一样。他们可能会做非常相似的事情,但不再是同一件事。这是一个重要的问题,该语言试图避免这种情况。

这与系统可以做什么无关。我敢肯定,鉴于当时存在的信息,任何给定语言的任何给定版本都可以支持各种各样的事情。但是应该吗?完全是另一个问题。在这种情况下,似乎支持它的成本将大大超过人们从中获得的收益。

关于c# - 为什么条件方法必须具有void的返回类型?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/46425932/

10-10 18:30
查看更多