I am working with some classes that wrap unmanaged APIs, so I have to be concerned with releasing the resources associated with these APIs-- eg, the IDisposable interface. I was a little confused about the distinction between Dispose() and Finalize(), and in my research I found this article by Brent Rector of Wintellect:
In a worst-case scenario, your object's Finalize method won't run until your process terminates gracefully. (Actually, the real worst case is that it never runs at all because the process terminates abnormally.) Shortly thereafter, non-memory resources will be released anyway, so the Finalize method served no real purpose other than to keep the application from running as fast as it otherwise could.It's a good point. In a true worst case scenario-- unhandled exception time-- you won't get any benefit from Finalize. So, given the (evidently) large performance penalty of Finalize, why bother? I tend to agree. However, the best practice according to Microsoft is, if you implement IDispose, you should also implement a Finalizer:Just say No to Finalize methods!
Private _IsDisposed as Boolean = False ''' <summary> ''' public Dispose method intended for client use ''' </summary> Public Overloads Sub Dispose() Implements IDisposable.Dispose Dispose(False) GC.SuppressFinalize(Me) End Sub ''' <summary> ''' common Dispose method; can be called by client or the runtime ''' </summary> Protected Overridable Overloads Sub Dispose(ByVal IsFinalizer As Boolean) If Not _IsDisposed Then If IsFinalizer Then '-- dispose unmanaged resources End If '-- disposed managed resources End If _IsDisposed = True End Sub ''' <summary> ''' called by the runtime only, at garbage collection time ''' this protects us if the client "forgets" to call myObject.Dispose() ''' </summary> Protected Overrides Sub Finalize() Dispose(True) End Sub
It's all rather contradictory.