blocks|key|4596|text|在关闭流或其他非托管对象时，应使用Dispose模式，而不是析构函数。你永远不会知道那个析构函数什么时候会触发。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4597|关于析构函数中空条件运算符的使用:我认为运算符本身没有问题。我会引用其他可能已经被析构或正在销毁的对象。|4598|entityMap^0|H|7|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

When you are closing streams or other unmanaged objects, you should use the <code>Dispose</code> pattern, rather than a destructor. You never know when that destructor will fire.

Regarding the use of the null conditional operator in a destructor: I see no problem with the operator itself. I do with referencing other objects that might already been destructed or in destruction.

blocks|key|3979|text|请不要在终结器中使用任何引用类型的字段:+GC+(垃圾收集器)收集它们的顺序是不可预测的，这就是为什么|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3980|+~clsSAPSettings()
+{
+++++mtbTemp?.Close();
+}|code-block|syntax|javascript|3981|GC可以很好地执行如下代码：|3982|3983|Collect+mtbTemp+instance|ordered-list-item|offset|length|style|CODE|3984|Start+Collect+this+instance：|3985|调用call+mtbTemp?.Close();，即调用所收集(销毁)的实例的方法|3986|3987|这样你就会有一个不稳定的很难找到的错误。看起来您正在寻找一个IDisposable接口：|3988|+public+class+clsSAPSettings:+IDisposable+{
+++private+MyTemp+mtbTemp;

+++...+

+++protected+virtual+void+Dispose(bool+disposing)+{
+++++if+(disposing)+{+
++++++++mtbTemp?.Close();

++++++++GC.SuppressFinalize(this);+
+++++}
+++}++

+++public+void+Dispose()+{
+++++Dispose(true);
+++}

+++//TODO:+do+you+really+want+finalizer?
+++~clsSAPSettings()+{
+++++Dispose(false);
+++}+
+}|3989|entityMap^0|0|0|0|0|8|7|0|E|4|0|7|H|0|0|U|B|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|12|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|13|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|15|8|@$M|16|N|17|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|L|7|18|8|@$M|19|N|1A|O|P]]|9|@]|A|$]]|$1|S|3|T|5|L|7|1B|8|@$M|1C|N|1D|O|P]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1F|8|@$M|1G|N|1H|O|P]]|9|@]|A|$]]|$1|X|3|Y|5|D|7|1I|8|@]|9|@]|A|$E|F]]|$1|Z|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|10|$]]

Please do not use any fields of reference types in the finalizer: the order in which GC (Garbage Collector) collects them is unpredictable and that's why

<pre><code> ~clsSAPSettings()
 {
 mtbTemp?.Close();
 }
</code></pre>

code can well be performed by GC as followes:

<ol>
<li>Collect <code>mtbTemp</code> instance</li>
<li>Start collecting <code>this</code> instance:</li>
<li>Call <code>~clsSAPSettings()</code></li>
<li>Call <code>mtbTemp?.Close();</code> i.e. call a method of the collected (destroyed) instance</li>
</ol>

and you'll have an unstable hard to find error. It seems that you are looking for a <code>IDisposable</code> interface:

<pre><code> public class clsSAPSettings: IDisposable {
 private MyTemp mtbTemp;

 ... 

 protected virtual void Dispose(bool disposing) {
 if (disposing) { 
 mtbTemp?.Close();

 GC.SuppressFinalize(this); 
 }
 } 

 public void Dispose() {
 Dispose(true);
 }

 //TODO: do you really want finalizer?
 ~clsSAPSettings() {
 Dispose(false);
 } 
 }
</code></pre>

blocks|key|4023|text|考虑一下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4024|~clsSAPSettings()
{++++
++++mtbTemp?.Close();
}|code-block|syntax|javascript|4025|这里的问题不是null条件用法。这本身并不会带来任何问题。|4026|最大的问题是，在终结器中，你不应该接触任何其他的对象。当终结器触发时，你的对象就结束了。你不再对mtbTemp的生命周期有任何保证，包括它是否已经被垃圾回收，所以你的不应该接触它。它可能会起作用；它可能会导致暂时的复活，或者它可能会可怕地崩溃。|offset|length|style|CODE|BOLD|4027|这样做的正确位置是在IDisposable.Dispose中。在Dispose方法中，这绝对没问题：|4028|public+void+Dispose()+//+where+your+class+:+IDisposable
{++++
++++mtbTemp?.Close();
++++mtbTemp+=+null;
}|4029|你可能根本不需要终结器。它们非常稀有。|4030|entityMap^0|0|0|0|1C|7|2B|6|0|A|J|W|7|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Y|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|10|8|@$K|11|L|12|M|N]|$K|13|L|14|M|O]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|15|8|@$K|16|L|17|M|N]|$K|18|L|19|M|N]]|9|@]|A|$]]|$1|R|3|S|5|D|7|1A|8|@]|9|@]|A|$E|F]]|$1|T|3|U|5|6|7|1B|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|W|$]]

Consider:

<pre><code>~clsSAPSettings()
{ 
 mtbTemp?.Close();
}
</code></pre>

The problem here isn't the null conditional usage. That doesn't by itself present any issues.

The biggest problem is that in a finalizer you should not touch any other object. When the finalizer fires, your object is toast. You no longer have any guarantees about the life of <code>mtbTemp</code>, including whether or not it has already been garbage collected, so you should not touch it. It might work; it might cause a temporary resurrection, or it might crash horribly.

The correct place to do something like this is in <code>IDisposable.Dispose</code>. In the <code>Dispose</code> method, that would be absolutely fine:

<pre><code>public void Dispose() // where your class : IDisposable
{ 
 mtbTemp?.Close();
 mtbTemp = null;
}
</code></pre>

You probably don't need a finalizer at all. They are incredibly rare.

I have a class with a destructor that I get a null reference exception from because the variable I destroy is sometimes <code>null</code>.

Is this an appropriate use of the null conditional operator to be in the destructor? 

I'm not even sure if this is an appropriate use of a destructor itself since it is not used to dispose of the actual object it's called on but rather a variable of it. 

<pre><code>~clsSAPSettings()
{

 mtbTemp?.Close();
}
</code></pre>

This code was converted from VB6 so I'm trying to figure out how to handle this issue. Any information welcome.

<hr>

Edit: The class <code>mtbTemp</code> belongs to implements <code>IDisposable</code> but doesn't have a finaliser/desctructor. It simply closes a connection used in an ORM model. 

<hr>

For anyone after a detailed explanation I found a great answer, <a href="https://stackoverflow.com/questions/538060/proper-use-of-the-idisposable-interface">Proper use of the IDisposable interface</a>, it goes into detail about the use of finalizer and how garbage collection actually works.

Is using the null conditional operator in a destructor bad practice?

我有一个带有析构函数的类，我从中得到了一个空引用异常，因为我销毁的变量有时是null。在析构函数中使用空条件运算符合适吗？我甚至不确定这是否是析构函数本身的恰当使用，因为它不是用来处理被调用的实际对象的，而是它的一个变量。~clsSAPSettings(){    mtbTemp?.Close();}这段代码是从VB6...

问在析构函数中使用null条件运算符是不是很糟糕？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在析构函数中使用null条件运算符是不是很糟糕？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在析构函数中使用null条件运算符是不是很糟糕？
EN