这个模式好吗？ [英] Is this pattern OK?
问题描述
嗨大师，
使用.NET 2 C＃Web应用程序。使用
System.DirectoryServices可以从AD读取信息。那个
似乎是那个DLL的.NET 1.1实现中的几个错误
和习惯我现在非常积极地处理对象当我是
用它们完成。
这种模式有什么问题：
DirectoryEntry objADAM = null;
DirectorySearcher objSearchADAM = null;
SearchResultCollection objSearchResults = null;
尝试
{
objADAM = new DirectoryEntry（ldap，admin，pass，
AuthenticationTypes.Secure）;
objSearchADAM = new DirectorySearcher（objADAM）;
objSearchResults = objSearchADAM.FindAll（）;
//用搜索结果做点什么
objSearchResults.Dispose（）;
}
catch（例外情况）
{
//处理任何错误
}
终于
{
objSearchADAM.Dispose（）;
objADAM.Dispose（）;
objSearchResults.Disp ose（）;
}
我问的原因是这个确切的模式存在于我们的一个web
应用程序中我们最近从.NET 1.1更新。到.NET 2.0。在
上周它一直在随机抛出空引用异常。
我无法重新创建导致异常的原因，但它可以是
通过在IIS中回收应用程序解决。上周对
服务器的唯一更改是KB943485和KB941644的应用。
查看堆栈跟踪表明空引用异常是
即将上线：
objSearchResults.Dispose（）;
在finally {}块内。所以我假设我应该删除
首次调用Dispose（），并将finally {}块或
中的所有内容更改为finally {}块。 ：
if（objSearchResults！= null）
objSearchResults.Dispose（）;
我可以做的事情这就是为什么上周才开始在
开始了！
非常感谢任何建议，Richard
2008年1月18日星期五08:57:50 -0800， ri **************** @ eshareuk.com
< ri ****** **********@eshareuk.comwrote：
[...]
查看堆栈跟踪指示空引用异常是
即将上线：
objSearchResults.Dispose（）;
变量是objSearchResults吗？当你试图执行该行时为null？
如果是这样，那么我会说是的......这个模式出现了问题，
_somewhere_。你不应该在空引用上调用方法，而不是
甚至Dispose（）。
现在，我在文档中看不到任何内容对于DirectorySearcher.FindAll（），
建议它应该返回一个空值。因此，如果异常在该行的第一个实例上有
，则在尝试之内。你的
代码的一部分，看起来像是DirectorySearcher类中的一个bug。
但是，因为它在finally中。部分你的代码，然后我怀疑
你得到一个异常，然后变量可以初始化为
非空值，所以你当然得到当你尝试在null引用上调用
Dispose（）时出现异常。
在finally {}块中。所以我假设我应该删除
首次调用Dispose（），并将finally {}块或
中的所有内容更改为finally {}块。 ：
if（objSearchResults！= null）
objSearchResults.Dispose（）;
您应该删除第一次调用Dispose（）_并且更改finally
块以检查变量的值在调用Dispose（）之前为null。
在调用
Dispose（）之前，你应该同样检查_all_你的对象为null，因为你无法保证它们是
$ b输入finally时$ b为非null阻止。
我无法解决的问题是为什么这只是在上周开始发生在
！
听起来你得到了一个以前没有发生的新例外。
错误始终在代码中，但你从来没有碰过它。至于
异常可能是什么以及为什么它刚刚开始发生，谁知道呢？
你可能只是幸运，或者可能是对系统的一些更新
稍微改变了行为，或者它可能是其他的东西。
但是代码首先是错误的，所以要做的第一件事是修复
吧。
Pete
< ri **************** @ eshareuk.comwrote in message
新闻：8b ********************************** @ h11g2000 prf.googlegroups.com。 ..
嗨大师，
System.DirectoryServices可以从AD读取信息。那个
似乎是那个DLL的.NET 1.1实现中的几个错误
和习惯我现在非常积极地处理对象当我是
用它们完成。
这种模式有什么问题：
DirectoryEntry objADAM = null;
DirectorySearcher objSearchADAM = null;
SearchResultCollection objSearchResults = null;
尝试
{
objADAM = new DirectoryEntry（ldap，admin，pass，
AuthenticationTypes.Secure）;
objSearchADAM = new DirectorySearcher（objADAM）;
objSearchResults = objSearchADAM.FindAll（）;
//用搜索结果做点什么
objSearchResults.Dispose（）;
}
catch（例外情况）
{
//处理任何错误
}
终于
{
objSearchADAM.Dispose（）;
objADAM.Dispose（）;
objSearchResults.Dispose（） ;
}
我问的原因是我们最近更新的一个web
应用程序中存在这种确切模式来自.NET 1.1。到.NET 2.0。在
上周它一直在随机抛出空引用异常。
我无法重新创建导致异常的原因，但它可以是
通过在IIS中回收应用程序解决。上周对
服务器的唯一更改是KB943485和KB941644的应用。
查看堆栈跟踪表明空引用异常是
即将上线：
objSearchResults.Dispose（）;
在finally {}块内。所以我假设我应该删除
首次调用Dispose（），并将finally {}块或
中的所有内容更改为finally {}块。 ：
if（objSearchResults！= null）
objSearchResults.Dispose（）;
你应该做的是转换try / finally {Dispose（）;使用块来自动处理空案例。
>
我可以做的事情这就是为什么上周才开始在
开始了！
非常感谢任何建议，Richard
1月18日下午1点58分，Ben Voigt [C ++ MVP]" < r ... @nospam.nospamwrote：
< richard.markiew ... @ eshareuk.comwrote in message
新闻：8b ********************************** @ h11g2000 prf.googlegroups.com ...
嗨Gurus，
使用.NET 2 C＃Web应用程序。使用
System.DirectoryServices可以从AD读取信息。那个
似乎是那个DLL的.NET 1.1实现中的几个错误
和习惯我现在非常积极地处理对象当我是
用它们完成。
这种模式有什么问题：
DirectoryEntry objADAM = null;
DirectorySearcher objSearchADAM = null;
SearchResultCollection objSearchResults = null;
try
{
objADAM = new DirectoryEntry（ldap，admin，pass，
AuthenticationTypes.Secure）;
objSearchADAM = new DirectorySearcher（objADAM）;
objSearchResults = objSearchADAM.FindAll（）;
//使用搜索结果执行某些操作
objSearchResults。 Dispose（）;
}
catch（exception ex）
{
//处理任何错误
}
终于
{
objSearchADAM.Dispose（）;
objADAM.Dispose （）;
objSearchResults.Dispose（）;
}
我问的原因这个确切的模式存在于我们最近从.NET 1.1更新的一个web
应用程序中。到.NET 2.0。在
上周它一直在随机抛出空引用异常。
我无法重新创建导致异常的原因，但它可以是
通过在IIS中回收应用程序解决。上周对
服务器的唯一更改是应用KB943485和KB941644。
查看堆栈跟踪表明空引用异常是
即将上线：
objSearchResults.Dispose（）;
在finally {}块中。所以我假设我应该删除
首次调用Dispose（），并将finally {}块或
中的所有内容更改为finally {}块。 ：
if（objSearchResults！= null）
objSearchResults.Dispose（）;
你应该做的是转换try / finally {Dispose（）;使用块自动处理空的情况下使用块进入
。
我无法解决的问题是为什么这只会开始发生在上周的
！
非常感谢任何建议，Richard
谢谢你们俩为你输入Pete和Ben。
我所做的就是按照Ben的建议继续进行，然后用一个using语句替换
finally {}块。我的所有DirectoryEntries，
DirectorySearchers和SearchResultCollections。这肯定更容易
看看那是怎么回事。
希望这会解决问题:)
我看到即使对于最新版本的框架，MS仍然
说：
由于实施限制， SearchResultCollection类
无法释放所有非托管资源，因为它是垃圾收集的
。为了防止内存泄漏，当不再需要SearchResultCollection对象时，必须调用Dispose方法
。
这可能与某些事情有关COM背后的东西
场景。
如果我的代码看起来像这样，你们其中一个人可以确认：
尝试
{
使用（DirectoryEntry objADAM = new DirectoryEntry（ldap，admin，
pass，AuthenticationTypes.Secure）
{
使用（DirectorySearcher objSearchADAM = new
DirectorySearcher（objADAM）
{
使用（SearchResultCollection objSearchResults =
objSearchADAM.FindAll（））
{
//用搜索结果做点什么
}
}
}
}
catch（例外情况）
{
//处理错误
}
如果我的AD代码遇到try {}内的问题，我的所有目录
对象wi会被处理？这是实现的正确模式
在这种情况下使用{}
再次感谢您的帮助
Richard
Hi Gurus,
Working with a .NET 2 C# web application. Using
System.DirectoryServices a lot to read information from AD. There
seemed to be several bugs in the .NET 1.1 implementation of that DLL
and out of habit I now very aggressively dispose of objects when I''m
done with them.
Is there anything wrong with this pattern:
DirectoryEntry objADAM = null;
DirectorySearcher objSearchADAM = null;
SearchResultCollection objSearchResults = null;
try
{
objADAM = new DirectoryEntry(ldap, admin, pass,
AuthenticationTypes.Secure);
objSearchADAM = new DirectorySearcher(objADAM);
objSearchResults = objSearchADAM.FindAll();
//Do something with the search results
objSearchResults.Dispose();
}
catch(Exception ex)
{
//Handle any errors
}
finally
{
objSearchADAM.Dispose();
objADAM.Dispose();
objSearchResults.Dispose();
}
The reason I ask is that this exact pattern exists in one of our web
applications that we recently updated from .NET 1.1. to .NET 2.0. In
the last week it has been randomly throwing null reference exceptions.
I cannot recreate what is causing the exception, but it can be
resolved by recycling the application in IIS. The only change to the
server in the last week is application of KB943485 and KB941644.
Looking at the stack trace indicates the null reference exception is
coming on the line:
objSearchResults.Dispose();
Within the finally{} block. So I assume I should either remove the
first call to Dispose(), and have everything in the finally{} block or
change the finally{} block to something like:
if(objSearchResults != null)
objSearchResults.Dispose();
The thing I can''t work out is why this only started happening in the
last week!
Many thanks for any advice, Richard
On Fri, 18 Jan 2008 08:57:50 -0800, ri****************@eshareuk.com
<ri****************@eshareuk.comwrote:
[...]
Looking at the stack trace indicates the null reference exception is
coming on the line:
objSearchResults.Dispose();Is the variable "objSearchResults" null when you try to execute that line?
If so, then I''d say yes...there''s something wrong with this "pattern",
_somewhere_. You shouldn''t be calling methods on null references, not
even Dispose().
Now, I don''t see anything in the docs for DirectorySearcher.FindAll() that
suggests it should ever return a null value. So, if the exception had
been on the first instance of that line, within the "try" part of your
code, that would have seemed like a bug in the DirectorySearcher class.
However, since it''s in the "finally" part of your code, then I suspect
you''re getting an exception before the variable can be initialized to a
non-null value, and so of course you get an exception when you try to call
Dispose() on the null reference.
Within the finally{} block. So I assume I should either remove the
first call to Dispose(), and have everything in the finally{} block or
change the finally{} block to something like:
if(objSearchResults != null)
objSearchResults.Dispose();You should remove the first call to Dispose() _and_ change the "finally"
block to check the variable''s value for null before calling Dispose().
You should similarly check _all_ of your objects for null before calling
Dispose() on them, since you have no way to guarantee that they are
non-null when entering the "finally" block.
The thing I can''t work out is why this only started happening in the
last week!Sounds like you''re getting a new exception that didn''t happen before. The
bug was always in the code, but you just never hit it. As for what the
exception might be and why it''s just now starting to happen, who knows?
You may just have been lucky, or it may be that some update to the system
has changed the behavior slightly, or it could be something else.
But the code was wrong in the first place, so the first thing to do is fix
it.
Pete
<ri****************@eshareuk.comwrote in message
news:8b**********************************@h11g2000 prf.googlegroups.com...Hi Gurus,
Working with a .NET 2 C# web application. Using
System.DirectoryServices a lot to read information from AD. There
seemed to be several bugs in the .NET 1.1 implementation of that DLL
and out of habit I now very aggressively dispose of objects when I''m
done with them.
Is there anything wrong with this pattern:
DirectoryEntry objADAM = null;
DirectorySearcher objSearchADAM = null;
SearchResultCollection objSearchResults = null;
try
{
objADAM = new DirectoryEntry(ldap, admin, pass,
AuthenticationTypes.Secure);
objSearchADAM = new DirectorySearcher(objADAM);
objSearchResults = objSearchADAM.FindAll();
//Do something with the search results
objSearchResults.Dispose();
}
catch(Exception ex)
{
//Handle any errors
}
finally
{
objSearchADAM.Dispose();
objADAM.Dispose();
objSearchResults.Dispose();
}
The reason I ask is that this exact pattern exists in one of our web
applications that we recently updated from .NET 1.1. to .NET 2.0. In
the last week it has been randomly throwing null reference exceptions.
I cannot recreate what is causing the exception, but it can be
resolved by recycling the application in IIS. The only change to the
server in the last week is application of KB943485 and KB941644.
Looking at the stack trace indicates the null reference exception is
coming on the line:
objSearchResults.Dispose();
Within the finally{} block. So I assume I should either remove the
first call to Dispose(), and have everything in the finally{} block or
change the finally{} block to something like:
if(objSearchResults != null)
objSearchResults.Dispose();What you ought to do instead is convert try / finally { Dispose(); } into
using blocks, which automatically handle the null case.
>
The thing I can''t work out is why this only started happening in the
last week!
Many thanks for any advice, Richard
On Jan 18, 1:58 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:<richard.markiew...@eshareuk.comwrote in message
news:8b**********************************@h11g2000 prf.googlegroups.com...
Hi Gurus,
Working with a .NET 2 C# web application. Using
System.DirectoryServices a lot to read information from AD. There
seemed to be several bugs in the .NET 1.1 implementation of that DLL
and out of habit I now very aggressively dispose of objects when I''m
done with them.
Is there anything wrong with this pattern:
DirectoryEntry objADAM = null;
DirectorySearcher objSearchADAM = null;
SearchResultCollection objSearchResults = null;
try
{
objADAM = new DirectoryEntry(ldap, admin, pass,
AuthenticationTypes.Secure);
objSearchADAM = new DirectorySearcher(objADAM);
objSearchResults = objSearchADAM.FindAll();
//Do something with the search results
objSearchResults.Dispose();
}
catch(Exception ex)
{
//Handle any errors
}
finally
{
objSearchADAM.Dispose();
objADAM.Dispose();
objSearchResults.Dispose();
}
The reason I ask is that this exact pattern exists in one of our web
applications that we recently updated from .NET 1.1. to .NET 2.0. In
the last week it has been randomly throwing null reference exceptions.
I cannot recreate what is causing the exception, but it can be
resolved by recycling the application in IIS. The only change to the
server in the last week is application of KB943485 and KB941644.
Looking at the stack trace indicates the null reference exception is
coming on the line:
objSearchResults.Dispose();
Within the finally{} block. So I assume I should either remove the
first call to Dispose(), and have everything in the finally{} block or
change the finally{} block to something like:
if(objSearchResults != null)
objSearchResults.Dispose();
What you ought to do instead is convert try / finally { Dispose(); } into
using blocks, which automatically handle the null case.
The thing I can''t work out is why this only started happening in the
last week!
Many thanks for any advice, Richard
Thank you both for your input Pete and Ben.
What I have done is go ahead as Ben suggested and just replaced the
finally{} block with a using statement on all my DirectoryEntries,
DirectorySearchers and SearchResultCollections. It''s certainly easier
to see what''s going on that way.
Hopefully this will resolve the issue :)
I see that even for the latest versions of the Framework, MS still
say:
"Due to implementation restrictions, the SearchResultCollection class
cannot release all of its unmanaged resources when it is garbage
collected. To prevent a memory leak, you must call the Dispose method
when the SearchResultCollection object is no longer needed."
This is presumably something to do with the COM stuff going on behind
the scenes.
Can one of you confirm that if my code looks like this:
try
{
using(DirectoryEntry objADAM = new DirectoryEntry(ldap, admin,
pass, AuthenticationTypes.Secure)
{
using(DirectorySearcher objSearchADAM = new
DirectorySearcher(objADAM)
{
using(SearchResultCollection objSearchResults =
objSearchADAM.FindAll())
{
//Do something with the search results
}
}
}
}
catch(Exception ex)
{
//Handle the error
}
That if my AD code hits a problem inside the try{}, all my directory
objects will be disposed? This is the correct pattern for implementing
Using{} in this scenario?
Many thanks again for your help
Richard
这篇关于这个模式好吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
