C#/.NET 编译器是否有任何理由不对 Dispose() 发出警告?

Moo*_*ice 6 .net c# vb.net idisposable

就在我今天写一些IDisposable代码的时候,我正在考虑这个。

对于开发人员来说,Dispose()直接调用或者在对象的生命周期允许的情况下使用using构造是一种很好的做法。

我们需要担心的唯一实例是那些using由于我们的代码机制而无法使用的实例。但是我们应该在某个时候调用Dispose()这些对象。

鉴于 C# 编译器知道一个对象 implements IDisposable,它理论上也可以知道它Dispose()从未被调用过(它是一个非常聪明的编译器!)。它可能不知道当程序员应该做它的语义,但它可以作为一个很好的提醒,它永远不会调用,因为它从来没有在使用using结构和方法Dispose()从未直接调用,任何对象实现上IDisposable.

有什么原因吗,或者有没有想走这条路的想法?

Ser*_*rvy 2

理论上它也可以知道Dispose()从未调用过它

它可以在某些简单的情况下确定Dispose永远不会调用它。仅根据代码的静态分析,不可能确定所有创建的实例都将被丢弃代码根本不需要非常复杂,甚至可以直接估计对象是否未处理。

更糟糕的是,并非所有IDisposable对象实例都应该被释放。造成这种情况的原因可能有很多。有时,即使对象IDisposable只有一部分实例在实现中实际执行任何操作,也会实现该对象。(IEnumerator<T>就是一个很好的例子。大量的实现在处置时不执行任何操作,但有些实现会执行。如果您知道您所拥有的具体实现,则您不会在处置时执行任何操作;如果您不知道您需要确保您致电Dispose

还有一些类型Task实际上几乎不需要处理。(请参阅我需要处置任务吗?。)在绝大多数情况下,您不需要处置它们,并且不必要地用不执行任何using操作的块或处置调用使代码混乱,从而影响可读性。

  • 我不喜欢这样一种观念,即人们不应该在当前实现不执行任何操作的类上调用“Dispose”,即使这样做相对容易。在某些情况下,确保对象在适当的时间被处置是很困难的,并且如果知道该对象的特定类可以在不处置的情况下安全地放弃,那么如果明确注释了一个人的意图,则这种放弃可能是合理的。放弃对象而不进行处置的代码取决于该对象的实现细节,我希望最大限度地减少这种依赖性。 (3认同)