Is there a way to make sure Dispose() is called on exception during deserialization of an IDisposable class?

Question

in c#, i am deserializing an object of a type that implements IDisposable with the following statement (for illustration only).

XmlSerializer s = new XmlSerializer(typeof(MyDisposable))
MyDisposable o = (MyDispoable)s.Deserialize(filepath);

afaik, the serializer tries to construct the object using the default ctor and assigning all public properties and fields subsequently. In case there is any exception raised, i won't get my hands on the constructed object.

so, my question is if there is any way to make sure yet allocated resources are freed automatically. i am aware of the Dispose(bool disposing)-'pattern' implementing an explicit finalizer, but i'd feel more comfortable with freeing any resources explicitely (i.e. deterministically).

Answer 1

It seems the unusual case for a DTO to actually have resources to deallocate, so I can understand if it doesn't provide IDisposable support on failure (my own serializer doesn't, either - so I certainly can't criticize).

Perhaps change your class so that if it does have resources to dispose, it takes those resources lazily (i.e. not just when the type is deserialized).

XmlSerializer doesn't support callbacks, otherwise the final callback would be a possible option to eagerly load resources (a bit hacky, though).

Answer 2

Does your default constructor do something that would require a dispose? If yes, is this a good idea (especially for an object meant to be serialized in xml)? If no, then why are you worrying about it? Leave it for the garbage collector...

[Edit: Removed point about public fields, since its incorrect]
I'm also leaving this answer available for any educational value it may have -> read Marc's comment

Answer 3

If any exception is raised inside XmlSerializer.Deserialize method, it will propagate to the next catch method, and your object (o) will not be assigned. So unless you are using the properties setters to allocate some unmanaged resources during deserialization, I don't see why you should be concerned with manually disposing the object.

But if your class does allocate unmanaged resources, implementing IDisposable properly will mean that you will also release unmanaged resources from your object's finalizer, so that should be enough. There is no other way to call Dispose() on an object that didn't get assigned in the first place.

Having said that, I must admin that I've had several occasions where XmlSerializer would hang if the xml file was not completely valid during deserialization - so I ended up doing schema validation before deserialization, just to be sure everything goes fine.

Answer 4

How about calling GC.Collect(0, GCCollectionMode.Forced) after getting the exception?

Answer 5

A using clause is what you use to deterministically free resources

using (MyDisposible o = (MyDisposible)s.Deserialize (filepath)) { // Do stuff with 0 }

I would question why you want to do this though. In C# you only want to deterministically free things if they're tied to an external physical resource like an SQL connection or a File.

A garbage collector is asymptotically more efficient than manual memory management and it's good practice to allow memory references to simply go out of scope to be freed.

Answer 6

Disposer and Finalizer are NOT the same thing in C#.

A disposer implements a call to explicitly dispose your resources used, but not the memory in them. The user of your object is required to call this.

You can use a finalizer in C# to guarantee that even if your disposer isn't called that you still don't leak resources. i.e .Net guarantees that it will try to run your disposer before it actually garbage collected.

XmlSerializer is responsible in it's call not to leak memory if there is an exception in the call. If this happens then you will have found a bug in .Net and feel free to report it. If you call deserialize and it throws an exception, you don't get the object back, it's gone...

.Net's garbage collector works by the way, it's one of the freebies you get with a managed language, in that you don't have to worry about cleaning up your memory (in most cases) so you can focus more on what your code is doing and get that right.