Normally, one writes code something like this to download some data using a WebRequest.
using(WebResponse resp = request.GetResponse()) // WebRequest request...
using(Stream str = resp.GetResponseStream())
; // do something with the stream str
Now if a WebException is thrown, the WebException has a reference to the WebResponse object, which may or may not have Dispose called (depending on where the exception has happened, or how the response class is implemented) - I don't know.
My question is how one is supposed to deal with this. Is one supposed to be coding very defensively, and dispose of the response in the WebException object (that would be a little weird, as WebException is not IDisposable). Or is one supposed to ignore this, potentially accessing a disposed object or never disposing an IDisposable object?
The example given in the MSDN documentation for WebException.Response is wholly inadequate.
I have had a quick peek with Reflector, and can now say:
WebResponse, being an abstract class, delegates all its closing/disposing behaviour to its derived classes.
HttpWebResponse, being the derived class you are almost certainly using here, in its close/dispose methods, is only concerned with disposing the actual response stream. The rest of the class state can be left to the GC's tender mercies.
It follows that it's probably safe to do whatever you like with regard to exception handling, as long as:
When you read the response stream from WebResponse in the try block, enclose it in a using block.
If you read the response stream from WebException in the catch block, enclose it in a using block as well.
There is no need to worry about disposing of WebException itself.
using (var x = GetObject()) {
statements;
}
is (almost) equivalent to
var x = GetObject();
try {
statements;
}
finally {
((IDisposable)x).Dispose();
}
so your object will always be disposed.
This means that in your case
try {
using (WebResponse resp = request.GetResponse()) {
something;
}
}
catch (WebException ex) {
DoSomething(ex.Response);
}
ex.Response will be the same object as your local resp object, which is disposed when you get to the catch handler. This means that DoSomething is using a disposed object, and will likely fail with an ObjectDisposedException.
HttpWebRequest internally makes a memory stream off the underlying network stream before throwing WebException, so there is no unmanaged resource associated with the WebResponse returned from WebException.Response.
This makes it unnecessary to call Dispose() on it. In fact, trying to dispose WebException.Response can cause headache and issues because you may have callers of your code that is attempting to read properties associated with it.
However it is a good practice that you should dispose any IDisposable objects you own. If you decide to do so, make sure you don't have code depending on being able to read WebException.Response properties and/or its stream. The best way would be you handle the exception and throw new type of exception so that you don't leak WebException up to the caller when possible.
And also consider moving to HttpClient which replaces HttpWebRequest.
Disclaimer: No warranty implied.
I'm pretty sure that when you have a using statement the object is disposed, regardless of how you exit the using block (Be it via exception, return or simply progressing through the function).
I suspect you'll find that the object inside the WebException has already been disposed if you let it leave the using block.
Remember, disposing of an object doesn't necessarily prevent accessing it later. It can be unpredictable to try to call methods on it later, causing exceptions of it's own or very weird behavior (And hence I wouldn't recommend it). But even still a large portion of the object is still left behind for the garbage collector even if you dispose it, and hence is still accessible. The purpose of the dispose is typically to clean up resource handles (Like in this case active TCP connections) that for performance reasons you can't realistically leave laying around until the garbage collector finds them. I only mention this to clarify that it's not mutually exclusive for it to be disposed and the exception to hold a reference to it.
A very interesting question (although worth pointing out that the WebResponse object will have been disposed as you exit the using). My gut feeling is that it doesn't really matter that you've got a reference to this disposed WebResponse object as long as you don't try to do anything "operational" with it.
You can probably still access certain properties on the instance for logging purposes (such as the ResponseUri) without getting an ObjectDisposedException, but overall reference held by the exception is not there so you can continue using the instance.
I'd be interested to see what others say.
I get similar cases in EF DB connections.
So i actually create a connections list.
At the end of game , i loop dispose all of them.
Related
One of my senior told me to use try/ finally block for all the methods to clear the initialized objects data.
for eg:
var serviceProxy = new NotificationServiceProxy();
try
{
return serviceProxy.GetNotifications(userID, request.Filters, request.FilterProperty, usertypeid);
}
finally
{
serviceProxy = null;
}
Is that a good practice? if i'm using try/ catch for all my methods to clear the initialized objects data.
Not in C#, use using instead:
using(var serviceProxy = new NotificationServiceProxy()){
serviceProxy.GetNotifications(userID, request.Filters, request.FilterProperty, usertypeid);
// Do stuff with the service proxy
}
// serviceProxy has now been cleaned up
This is the pattern to ensure that IDisposable variable get cleaned up.
For instances that aren't disposable this isn't needed - just let them pass out of scope and leave it to the GC.
If NotificationServiceProxy uses lots of resources and you need to be sure that it is finalised correctly then make it disposable and always wrap it in a using or in another class that also implements IDisposable. If it doesn't then this try-finally pattern is a waste of time.
No that's not a good practice.
You are doing work manually, the compiler/garbage collector will do for you. This is unnecessary time spent and unnecessary code clutter you need to remove or maintain later.
You completely missed to .Dispose() the service reference. Although this could be done in a finally block, the using block exists exactly for this purpose.
You don't need to clear a local variable. Before you exit the method, the stack will be reverted anyway (which will free up the space on the stack used by the variable) and setting the local variable to null will not free up space on the heap (the garbage collector will do that). Use try finally if you need to do some cleanup, for example object disposal or closing files.
Is it a good practice or not, it depends on the scenarios. It's often good to catch the exception so that you can handle unexpected cases gracefully. If your program has developed some other ways to handle exception cases then Try/Finally block should be suffice since Catch block have some performance penalties.
Please review the Consideration When Using Try Catch article from MSDN.
First of all, you have no need to clear the local variables (Garbage Collector will do it for you), however, it's safe:
Object o = new Object();
...
o = null; // safe, but not required
What you have to do is to clear unmanaged resources; typical way for this is implementing IDisposable interface and wrapping corresponding instances into using:
// Providing that serviceProxy implements IDisposable
using (var serviceProxy = new NotificationServiceProxy()) {
return serviceProxy.GetNotifications(
userID,
request.Filters,
request.FilterProperty,
usertypeid);
} // <- here .Net will call serviceProxy.Dispose() and free the resources allocated
sometime you have to restore the initial state, and that is the case try..finally has been designed for:
Cursor savedCursor = Cursor.Current;
try {
Cursor.Current = Cursors.WaitCursor;
...
}
finally {
// Rain (exception thrown) or shine (no exception), please, restore my cursor
Cursor.Current = savedCursor;
}
In your particular case, I can't see any state to restore, that's why try..finally is not the pattern that should be used. However, it's quite possible that serviceProxy allocates some unmanaged resources (say, TCP/IP port, connection or alike) so it seems that you should implement IDisposable for NotificationServiceProxy class (if it's not imlemented yet) and wrap the instance into using.
This makes sense when you need something that HAS to happen like Disposing IDisposable objects whether your operation has failed or succeeded.
try
{
myDisposable.Do();
}
finally
{
myDisposable.Dispose();
}
you have a built in mechanism which does exactly that : Using
using(IDisposable myDisposable = new Something())
{
myDisposable.Do();
}
Now has to good practice :
That's kinda up to your error handling strategy and cleanup needs :
If i have something that HAS to be done whether the operation succeed or failed i would put a try finally block.
if i have something that only need error handling and no cleanup i would place try catch without a finally block
If i have to do some kind of error handling i would also place a catch block in there
If i wan't to make some error handling there like a log and then have the Exception propagate from that stack i would also re throw the exception.
or any permutation of the above conditions ..
For instance :
try
{
myDisposable.Do();
}
catch(Exception e)
{
Log("Error at something something",e);
throw e;
}
finally
{
myDisposable.Dispose();
}
I for one do not place try catch finally every where, i want the places in my code that which do contain them stand out stating that these are operations that are known to go wrong for some known reason.
i would welcome new exceptions i'm not yet aware of and handle them accordingly.
Yes, if you need to dispose a variables.
I have found the following construct in some open-source code:
var mstream = new MemoryStream();
// ... write some data to mstream
mstream.Close();
byte[] b = mstream.GetBuffer();
I thought this code would have "unexpected" behavior and maybe throw an exception, since the call to Close should effectively be a call to Dispose according to the MSDN documentation.
However, as far as I have been able to tell from experimenting, the call to GetBuffer() always succeeds and returns a valid result, even if I Thread.Sleep for 20 seconds or enforce garbage collection via GC.Collect().
Should the call to GetBuffer() succeed even after Close/Dispose? In that case, why is not the underlying buffer released in the MemoryStream disposal?
It doesn't need to. The buffer is managed memory, so normal garbage collection will deal with it, without needing to be included in the disposal.
It's useful to be able to get the bytes of the memory stream, even after the stream has been closed (which may have happened automatically after the steam was passed to a method that writes something to a stream and then closes said stream). And for that to work, the object needs to hold onto the buffer along with a record of how much had been written to it.
In considering the second point, it actually makes more sense in a lot of cases to call ToArray() (which as said, requires the in-memory store that GetBuffer() returns to still be alive) after you've closed the stream, because having closed the stream guarantees that any further attempt to write to the stream will fail. Hence if you have a bug where you obtain the array too early, it will throw an exception rather than just give you incorrect data. (Obviously if you explicitly want to get the current array part-way through the stream operations, that's another matter). It also guarantees that all streams are fully flushed rather than having part of their data in a temporary buffer (MemoryStream isn't buffered because MemoryStream essentially is a buffer, but you may have been using it with chained streams or writers that had their own separate buffer).
Technically there's nothing to dispose in MemoryStream. Literally nothing, it doesn't have operating system handles, unmanaged resources, nothing. it is just a wrapper around byte[]. All what you can do is set the buffer(internal array) to null, that BCL team hasn't done for some reason.
As #mike noted in comments BCL team wanted GetBuffer and ToArray to work, even after disposed, though we're not sure why?. Reference source.
Here's how Dispose implemented.
protected override void Dispose(bool disposing)
{
try {
if (disposing) {
_isOpen = false;
_writable = false;
_expandable = false;
// Don't set buffer to null - allow GetBuffer & ToArray to work.
#if FEATURE_ASYNC_IO
_lastReadTask = null;
#endif
}
}
finally {
// Call base.Close() to cleanup async IO resources
base.Dispose(disposing);
}
}
and GetBuffer is below
public virtual byte[] GetBuffer()
{
if (!this._exposable)
{
throw new UnauthorizedAccessException(Environment.GetResourceString("UnauthorizedAccess_MemStreamBuffer"));
}
return this._buffer;
}
As you can see in Dispose _buffer is untouched, and in GetBuffer no disposed checks.
Since the GC is non-deterministic you cannot force it to immediately dispose the MemoryStream, thus the instance will not be marked as disposed immediately, instead it will just be marked for disposal. This means that for some time, until it is really disposed you can use some of its functions. Since it keeps a strong reference to its buffer you can get it, here is what the GetBuffer method looks like:
public virtual byte[] GetBuffer()
{
if (!this._exposable)
{
throw new UnauthorizedAccessException(Environment.GetResourceString("UnauthorizedAccess_MemStreamBuffer"));
}
return this._buffer;
}
Unlike most interface methods, the IDisposable.Dispose does not promise to do anything. Instead, it provides a standard means by which the owner of an object can let that object know that its services are no longer required, in case the object might need to make use of that information. If an object has asked outside entities to do something on its behalf, and has promised those outside entities that it will let them know when their services are no longer required, its Dispose method can relay the notification to those entities.
If an object has a method which can only be performed while the object has outside entities acting on its behalf, an attempt to call that method after those entities have been dismissed should throw an ObjectDisposedException rather than failing in some other way. Further, if there is a method which cannot possibly be useful after the entity is dismissed, it should often throw ObjectDisposedException even if a particular didn't actually need to use the entity. On the other hand, if a particular call would have a sensible meaning after an object has dismissed all entities that were acting on its behalf, there's no particular reason why such a call shouldn't be allowed to succeed.
I would view the ObjectDisposedException much like I view the collection-modified InvalidOperationException of IEnumerator<T>.MoveNext(): if some condition (either Dispose, or modification of a collection, respectively) would prevent a method from behaving "normally", the method is allowed to throw the indicated exception, and is not allowed to behave in some other erroneous fashion. On the other hand, if the method is capable of achieving its objectives without difficulty, and if doing so would make sense, such behavior should be considered just as acceptable as would be throwing an exception. In general, objects are not required to operate under such adverse conditions, but sometimes it may be helpful for them to do so [e.g. enumeration of a ConcurrentDictionary will not be invalidated by changes to the collection, since such invalidation would make concurrent enumeration useless].
While programming over an existent class, I've noticed that someone has written something like this:
using(DisposableObject disp = new DisposableObject())
{
...
...
disp.Dispose()
}
And then I wonder: isn't the using block enough to dispose an object? Could be there any way Dispose() can be useful in such case?
Cause it doesn't make any sense to me...
In your case it is useless to use dispose inside using because when using statement's scope ends it automatically calls dispose. That's why you can only write objects which implements IDisposable Interface inside using brackets.
using(.......)
Moreover if there was any statement using disp object after disp.Dispose() it would give an error, because by then object would have been disposed, i.e. its memory has been released.
But beware
If dispose is last line before using scope ends then it is useless.
But it is not useless when there are more lines after dispose.
Yes, a using block is actually equivalent to and an alternative syntax for:
var d = new DisposableObject();
try
{
d.DoSomething();
}
finally
{
if(d != null)
((IDisposable)d).Dispose();
}
Note that it uses finally instead of something like 'catch'. The finally-clause will always be executed, even if there's an exception.
using is enough. There is no reason to call Dispose twice.
There are two reasons why you can use Dispose inside a using block:
you want to dispose the object before the using block ends. In this case the using block is a "safety net" that ensures you that your object will be disposed even if an exception happens. (using behaves like a try block which has a finally block in which your object is disposed)
calling Dispose makes more clear what you're doing. This is typical, i.e. of
transaction scopes:
using(TransactionScope ts=new TransactionScope)
{
...
if (cond)
{
ts.Complete();
}
else
{
ts.Dispose(); // makes it clear you're rolling back the transaction
}
}
This call to Dispose it's not neccesary, but it's "explanatory". It makes more obvous that the transaction is rolled back.
#Nikhil Agrawal is right. One thing I need mention is when you implement Idisposable interface, you should make sure it can be invoked many times. That's mean you should do some validation.
I have the following code:
WebRequest request = WebRequest.Create("ftp://myServer/myDirectory");
request.Method = WebRequestMethods.Ftp.MakeDirectory;
request.Credentials = new NetworkCredential("userName", "password");
request.GetResponse();
Do I have to dispose of the WebResponse object that is returned by the WebRequest?
You should. Wrap it in using statement and it will be automatically disposed when going out of scope
using (var response = request.GetResponse())
{
}
As far as HAVE to dispose, I would say no. When the CLR detects there are no references to the object, the object will be scheduled for garbage collection. The problem you may run into is that there are no guarantees that the object and its attributes will be cleaned up in the correct order. Simple objects/classes, whether part of the .NET Framework or custom objects/classes rarely implement iDisposable interface. If an object/class implements iDisposable, you should definitely call the dispose methode to ensure proper handling of the clean up as the designer had some indication that it was necessary to clean up in a particular way. As stated by Stecya, wrapping in a using block is a great way to see this is done automatically. You could also use a try/finally block to achieve the same thing (disposing of the object in the finally block).
Yes you should. And you're right that that is not totally obvious, normally you should only Dispose objects you created (with new) and leave those you get/borrow from another component alone.
The key is in the name and description of WebRequest.Create(), it is a factory method that creates something on your behalf and the caller (you) is responsible for the return value.
And of course the preferred syntax is a using() {} block.
I was reading about this scenario where making use of the C# using statement can cause problems. Exceptions thrown within the scope of the using block can be lost if the Dispose function called at the end of the using statement was to throw an exception also. This highlights that care should be taken in certain cases when deciding whether to add the using statement.
I only tend to make use of using statements when using streams and the classes derived from DbConnection. If I need to clean up unmanaged resources, I would normally prefer to use a finally block.
This is another use of the IDisposable interface to create a performance timer that will stop the timer and log the time to the registry within the Dispose function.
http://thebuildingcoder.typepad.com/blog/2010/03/performance-profiling.html
Is this good use of the IDisposable interface? It is not cleaning up resources or disposing of any further objects. However, I can see how it could clean up the calling code by wrapping the code it is profiling neatly in a using statement.
Are there times when the using statement and the IDisposable interface should never be used? Has implementing IDisposable or wrapping code in a using statement caused problems for you before?
Thanks
I would say, always use using unless the documentation tells you not to (as in your example).
Having a Dispose method throw exceptions rather defeats the point of using it (pun intended). Whenever I implement it, I always try to ensure that no exceptions will be thrown out of it regardless of what state the object is in.
PS: Here's a simple utility method to compensate for WCF's behaviour. This ensures that Abort is called in every execution path other than when Close is called, and that errors are propogated up to the caller.
public static void CallSafely<T>(ChannelFactory<T> factory, Action<T> action) where T : class {
var client = (IClientChannel) factory.CreateChannel();
bool success = false;
try {
action((T) client);
client.Close();
success = true;
} finally {
if(!success) {
client.Abort();
}
}
}
If you find any other funny behaviour cases elsewhere in the framework, you can come up with a similar strategy for handling them.
The general rule of thumb is simple: when a class implements IDisposable, use using. When you need to catch errors, use try/catch/finally, to be able to catch the errors.
A few observations, however.
You ask whether situations exist where IDisposable should not be used. Well: in most situations you shouldn't need to implement it. Use it when you want to free up resources timely, as opposed to waiting until the finalizer kicks in.
When IDisposable is implemented, it should mean that the corresponding Dispose method clears its own resources and loops through any referenced or owned objects and calls Dispose on them. It should also flag whether Dispose is called already, to prevent multiple cleanups or referenced objects to do the same, resulting in an endless loop. However, all this is no guarantee that all references to the current object are gone, which means it will remain in memory until all references are gone and the finalizer kicks in.
Throwing exceptions in Dispose is frowned upon and when it happens, state is possibly not guaranteed anymore. A nasty situation to be in. You can fix it by using try/catch/finally and in the finally block, add another try/catch. But like I said: this gets ugly pretty quickly.
Using using is one thing, but don't confuse it with using try/finally. Both are equal, but the using-statement makes life easier by adding scoping and null-checks, which is a pain to do by hand each time. The using-statement translates to this (from C# standard):
{
SomeType withDispose = new SomeType();
try
{
// use withDispose
}
finally
{
if (withDispose != null)
{
((IDisposable)withDispose).Dispose();
}
}
}
There are occasions where wrapping an object into a using-block is not necessary. These occasions are rare. They happen when you find yourself inheriting from an interface that inherits from IDisposable just in case a child would require disposing. An often-used example is IComponent, which is used with every Control (Form, EditBox, UserControl, you name it). And I rarely see people wrapping all these controls in using-statements. Another famous example is IEnumerator<T>. When using its descendants, one rarely sees using-blocks either.
Conclusion
Use the using-statement ubiquitously, and be judicious about alternatives or leaving it out. Make sure you know the implications of (not) using it, and be aware of the equality of using and try/finally. Need to catch anything? Use try/catch/finally.
I think the bigger problem is throwing exceptions in Dispose. RAII patterns usually explicitly state that such should not be done, as it can create situations just like this one. I mean, what is the recovery path for something not disposing correctly, other than simply ending execution?
Also, it seems like this can be avoided with two try-catch statements:
try
{
using(...)
{
try
{
// Do stuff
}
catch(NonDisposeException e)
{
}
}
}
catch(DisposeException e)
{
}
The only problem that can occur here is if DisposeException is the same or a supertype of NonDisposeException, and you are trying to rethrow out of the NonDisposeException catch. In that case, the DisposeException block will catch it. So you might need some additional boolean marker to check for this.
The only case I know about is WCF clients. That's due to a design bug in WCF - Dispose should never throw exceptions. They missed that one.
One example is the IAsyncResult.AsyncWaitHandle property. The astute programmer will recognize that WaitHandle classes implement IDisposable and naturally try to greedily dispose them. Except that most of the implementations of the APM in the BCL actually do lazy initialization of the WaitHandle inside the property. Obviously the result is that the programmer did more work than was necessary.
So where is the breakdown? Well, Microsoft screwed up the IAsyncResult inteface. Had they followed their own advice IAsyncResult would have derived from IDisposable since the implication is that it holds disposable resources. The astute programmer would then just call Dispose on the IAsyncResult and let it decide how best to dispose its constituents.
This is one of the classic fringe cases where disposing of an IDisposable could be problematic. Jeffrey Richter actually uses this example to argue (incorrectly in my opinion) that calling Dispose is not mandatory. You can read the debate here.