强制垃圾收集或反映到私人领域，这是不是很邪恶？

Question

We have a third party library that internally uses a SafeHandle to an unmanaged resource. In some error cases it is necessary to dispose of the object and recreate it. But, there is a bug in the dispose implementation that prevents the Handle from being closed in a subset of these cases. Which prevents new objects from being successfully created until its finalizer runs.

Two solutions (both evil) have been proposed to deal with this until we can get the third party code fixed:

1. Run a GC.Collect to get the finalizer to run and clean up the object

2. Use reflection to get at the Handle and close it if dispose fails to do so

which of these is less evil and why? Is there some other method that we haven't considered that is less evil than either of these?

Answer 1

I'm in favour of private reflection. It's a localized bug, so the solution should be local too. And it's much clearer that what your code intends to do. And you probably can add some tests that notice once the bug has been fixed. So the hack can easily be removed once it's not needed anymore.

...
thirdPartyObject.Dispose();
ThirdPartyDisposeBugWorkaround(thirdPartyObject);
...

void ThirdPartyDisposeBugWorkaround(ThirdPartyClass thirdPartyObject)
{
   //Do private reflection here
}

Forcing a GC on the other hand has a global effect. And there are many reasons(most of them bad) for interfering with the GC. It's much less obvious what your code does. So the call might be kept even once the bug has been fixed.

Old New Thing: Don't use global state to manage a local problem

Answer 2

I would go with reflection, but make sure you have error handling around it that makes it explicitly clear what's wrong, keeping in mind the error might not get triggered until years from now and your dev team could have turned over and nobody remembers this wacky hack.

try
{
   .. hacky reflection ..
}
catch(Exception ex)
{
    throw new Exception("Reflection on private field 'Xyz' of 3rd Party Component 'Abc' failed.  Was 'Abc' updated? Reflection is used due to bug in 'Dispose' implementation.", ex);
}

Answer 3

First pick the one that works. If they both work pick the one that has the least amount of impact on the system. Gc.Collect is more of a hammer across the whole application. Where as your reflection code is brittle but should have a very small impact.

Answer 4

If it is not marked as sealed, you could inherit from it and implement your own dispose. As for the reflection vs GC, I would definately use reflection. Like others have said, the GC may not work as expected. It could do a collection iteration but not actually release your handle.

I would like to note: if something else still has a reference to this SafeHandle, and you release it, you could easily introduce other bugs into your system.

Answer 5

Taking the "CodeInChaos" argument forward why don't you call for collection on specific generation.

GC.GetGeneration(Object obj) will return the generation that object is in and GC.Collect(Int32 gen) .

Ex:

Int32 generation = GC.GetGeneration(theObject);
theObject = null;
GC.Collect(generation);
GC.WaitForPendingFinalizers();
GC.Collect(generation); // this is req because first collect puts thisObject on freachable queue not // garbaged yet.