Why do I need to call dispose on stringreader and stringwriter?

Question

it begins with me reading a stackoverflow answer

StringWriter implments public abstract class TextWriter : MarshalByRefObject, IDisposable

on MSDN it says:

The Framework provides the System.IDisposable interface that should be implemented to provide the developer a manual way to release unmanaged resources as soon as they are not needed.

but what is considered as unmanaged resources? I clearly don't think StringWriter qualifies. if I write my own without inheriting IDisposable....I don't see any need to add Dispose()

class ConfusedDevStringWriter{
   private StringBuilder sb;
   public ConfusedDevStringWriter(){ //ctor
      sb = new StringBuilder();
   }
}

And indeed I tested with visual studio memory debugger: once the function returns, StringWriter and its StringBuilder are freed...Moreoever, calling dispose seems to do nothing for StringWriter...

So not every class that inherit from IDisposable has useful Dispose. Again this goes back to my question what is considered as unmanaged resources (examples will be much appreciated n_n). I heard files are one of it...but isn't CLR a VM?...every resources should be managed by it, non?

You question "*what is considered as unmanaged resources*" already has answers: http://stackoverflow.com/questions/3433197/what-exactly-are-unmanaged-resources — Zein Makki, Oct 07 '16 at 20:52
Question in title answered more or less in http://stackoverflow.com/questions/234059/is-a-memory-leak-created-if-a-memorystream-in-net-is-not-closed (same Q about MemoryStream). — Alexei Levenkov, Oct 07 '16 at 20:57
I closed it as a duplicate of http://stackoverflow.com/questions/2475228, which between that and http://stackoverflow.com/questions/3433197 answers both questions. — D Stanley, Oct 07 '16 at 20:57
Don't understand why this question was closed. StringReader/StringWriter don't need to be disposed. From O'reilly's C# in a nutshell: " These types are disposable under the duress of their base class rather than through a genuine need to perform essential cleanup. If you happen to instantiate and work with such an object entirely in one method, wrapping it in a using block adds little inconvenience. But if the object is longer-lasting, keeping track of when it’s no longer used so that you can dispose of it adds unnecessary complexity. In such cases, you can simply ignore object disposal." — Maverick Meerkat, Jan 20 '18 at 22:40

score 2 · Answer 1 · answered Oct 07 '16 at 20:55

StringWriter descends from TextWriter, which implements IDisposable, probably because most TextWriters will have unmanaged resources. If you receive a TextWriter and you don't know where it came from (i.e. it might be any descendant of TextWriter), the fact that TextWriter implements IDisposable allows you to properly manage any unmanaged resources it has. You can write code that accepts any TextWriter, calls Dispose when the writer is no longer needed, and trust that everything will get cleaned up OK.

score 0 · Answer 2 · answered Oct 07 '16 at 20:55

0

StringWriter inherits from the abstract TextWriter, which implements IDisposable, and has some subclasses that do have unmanaged resources like streams, file handles, etc. So one can safely dispose of any subclass of TextWriter without having to worry about if the disposal is necessary or not.

So disposing of a StringWriter may not actually do anything (similar to DataSet), but it's still good practice to dispose of anything that implements IDisposable.

answered Oct 07 '16 at 20:55

D Stanley

149,601
11
178
240

1

I do not agree. It is NOT a good practice to call code that does nothing. It is actually bad practice. Programming languages are ment to "process"; not wait or do nothing. – Jonathan Alfaro Oct 20 '16 at 14:34
@Darkonekt Are there any guarantees that a Dispose function will never do anything and not be needed for a disposable class on dotnet core, mono, any wasm implementation, and full framework for every version current, past and future? If there is some consortium that can ensure this then I would consider not wrapping these classes in using statements. If there is no guarantee then I think your last statement is a dangerous one to make. – BillHaggerty Oct 08 '18 at 17:43
@Darkonekt I missed this comment or I would have responded similarly to Theyouthis. `IDisposable` is a contract, where the owner is _expected_ to call `Dispose` when done with the object. The caller should make no assumptions about whether the method actually does anything or not. Plus, it's perfectly plausible that some custom subclass of `StringWriter` _does_ do something in it's `Dispose`, so if you choose not to cal it, you might introduce a resource leak. – D Stanley Oct 08 '18 at 18:06
@DStanley you are now wondering in the world of "what if".... The reality is that calling code that does nothing is not correct. It is superfluous. And nothing demands that code needs to call every member of an interface. In this case in my opinion the interface is wrong because the object has no disposable objects so there is no need for it to implement such "contract". Just because others do it wrong it does not mean one also has to. – Jonathan Alfaro Oct 09 '18 at 03:46

Why do I need to call dispose on stringreader and stringwriter?

2 Answers2