Re: 'Set Object = Nothing'... do you still do this in VB.net????

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I said that WebRequest was off the top of my head.

It was actuallly WebResponse as Jon pointed out.

The documentation for the WebResponse.Close method explicity states (in the remarks) that the instance must be closed to avoid running out of system resources.

That's the only one I have encountered however I would find it difficult to accept that, among the thousand's of classes in the Framework, there are not other classes with a similar note.

One thing I am not going to do is go and find them for the sake of it.


"Andrew Morton" <akm@xxxxxxxxxxxxxxxxxxxxxx> wrote in message news:eTe3ldJFIHA.5328@xxxxxxxxxxxxxxxxxxxxxxx
Jon Skeet [C# MVP] wrote:
Andrew Morton <akm@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Stephany Young wrote:
There are some classes in the Framework where you MUST 'destroy' an
instance of it yourself. Off the top of my head, the WebRequest
class is one.

Assuming that is correct for the WebRequest class, how do you tell?
There is nothing I can see in the docs (framework 1.1) to say that
must be done, whereas, for example, System.Drawing.Bitmap has a
Dispose() method, although I suppose you have to infer from the
existence of a Dispose() method that it needs to be called.

You need to know that the class implements IDisposable. WebRequest was
an unfortunate example, as unfortunately it *doesn't* require
disposal, not implementing IDisposable.

Phew! I was getting worried there - I thought maybe there were classes that need to be disposed of yet no documentation saying so!

WebReponse, however, is a reasonable example.

Hmmm... in that particular case, doesn't WebResponse.Close take complete care of making it available for GC once it's gone out of scope? I see that WebResponse implements IDisposable but has no Dispose() method, and I haven't seen a memory leak in my ASP.NET application.

Andrew


.

Relevant Pages

  • Re: memory&handles growth due to not disposing command?
    ... however in my opinion Dispose should release ... > every "unmanaged resource". ... This is the primary function of Dispose. ... > never seen this in any official Microsoft documentation. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Problems Handling Errors Correctly
    ... I don't know enough about .NET to know what's going on under the covers but it sure seems like a lot is going on once you get exception handling nested 3 or 4 levels deep. ... However, you need not trace down the entire inheritance hierarchy to find that out A more reliable, one-stop-shopping page is the class's "Members" doc page, which will include interface members that are implemented in the class, whether they are direct or inherited. ... Knowing how to use the documentation is half the battle. ... similar methods as distinct from Dispose(), even where they appear to duplicate behavior. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: using statement is not behaving?
    ... > wrapper around some code that calls Dispose on the resource ... In the documentation it says that: ... The using block is behaving ... or that you're not seeing the finalization until later due to ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: In what order should files be clesed
    ... You also will want to make sure you call Flushon the writer before you attempt to use the stream in any other way, to ensure that the writer has no remaining buffered data to send to the stream. ... "This implementation of Close calls the Dispose method passing a true value". ... the documentation isn't always very clear. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: In what order should files be clesed
    ... It doesn't seem to be documented on MSDN that it does this. ... The docs for Dispose() are a bit round-about, saying only that "managed resources" are released calls Dispose, passing "true"). ... So if I want the stream to remain open, I shouldn't enclose the Writer in a using block, if I understand you and the documentation correctly. ...
    (microsoft.public.dotnet.languages.csharp)