Whether you view it as
an omission or not, it clearly was not addressed to its fullest extent until after the beta developer
community applied a gentle nudge. The problem stems, in part, from the garbage-collected
nature of objects in the CLR, coupled with the fact that the friendly destructor in the VB syntax
was reused to implement object finalizers. Finalizers are very different than destructors, and
using the destructor syntax for finalizers only added to the confusion of the matter.
The solution put on the table was the Disposable pattern, which you utilize by implementing
the IDisposable interface. Essentially, if your object needs deterministic destruction, it
obtains it by implementing the IDisposable interface. However, you have to call your Dispose
method explicitly in order to clean up after the disposable object. If you forget to, and your
object is coded properly, then the resource won??™t be lost??”rather, it will just be cleaned up when
the GC finally gets around to calling your finalizer.
Consider the following contrived example that illustrates the danger you can face:
Imports System
Imports System.IO
Imports System.Text
Public Class EntryPoint
Public Shared Sub DoSomeStuff()
Dim fs As FileStream = _
File.Open("log.
Pages:
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271