Closures, Deferred Execution and IDisposable

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Caddzooks - 22 Mar 2008 14:03 GMT

Can someone spot the problem here:

public class Form1 : Form
{
public Form1()
{
using( MyLockObject lockobj = new MyLockObject() )
{
Application.Idle += delegate( object sender, EventArgs e )
{
lockobj.Kaboom();
};
}
}
}

Because the delegate assigned to the Idle event references an object (MyLockObject) that will already have been disposed when the event fires, it will be attempting to use a disposed object.

This itself isn't the problem, as I know that if I want to reference that object from code that runs after the fact, I can't dispose the object in the ctor.

The question is, why doesn't the compiler catch it, and help the programmer avoid a very hideous bug?

Signature

caddzooks

Reply to this Message

Lasse Vågsæther Karlsen - 22 Mar 2008 14:18 GMT

> Can someone spot the problem here:
>
[quoted text clipped - 17 lines]
>
> The question is, why doesn't the compiler catch it, and help the programmer avoid a very hideous bug?

Well, in this particular case, the compiler would have to have lots of
assumptions about your code in order to warn you, and knowing these
assumptions might not be possible at all times.

Assumptions like:

- the Idle event is probably not going to be called in the constructor,
but much later (if you think about it, this is not an assumption about
the "Idle" event, but rather all events)
- the object is indeed unsafe to use after being Disposed (which is a
logical assumptions, but is no guarantee), in the manner it is used. For
instance, what if the method being called internally calls "IsDisposed"
and does nothing or something else that wouldn't crash in this case?

I don't think the C# compiler, without having a much more advanced
analysis engine, would be able to detect this reliable enough to warrant
this feature.

Resource tracking and proper usage is not easy. It's not *very* hard
either, but you need to know what you're doing, and in this case you're
yanking away the branch that the event is sitting on. The proper way
would be to unsubscribe the event before disposing of the object.

And I know what you asked, I'm just saying that I don't think it would
be possible to write a C# compiler that would detect all these nuances
and handle them with any guarantee as of the results.

Signature

Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3

Reply to this Message

Jeroen Mostert - 22 Mar 2008 14:26 GMT

> Can someone spot the problem here:
>
[quoted text clipped - 22 lines]
> The question is, why doesn't the compiler catch it, and help the
> programmer avoid a very hideous bug?

Because the general problem of detecting whether code contains an error is
unsolvable.

But more to the point, the very notion of "a disposed object" is outside the
realm of the language proper. As far the compiler is concerned, "using" is
just shorthand for a finally block with a .Dispose() call. It knows nothing
about what .Dispose() does.

Indeed, it is *not* an error (and potentially useful) to keep a reference to
a disposed object, and there's nothing in the language that makes it illegal
to call methods of an object on which .Dispose() has been called. The object
actually needs to check for this itself (and throw an
ObjectDisposedException if it's so inclined) and the caller needs to know
about this (or err on the safe side).

Garbage collection and finalization are under the survey of the compiler and
the runtime. IDispose and its implementation are not. Conceivably, a tool
like FxCop could be outfitted with a rule to detect this problem, like it
detects many other bad practices and potential problems that the compiler
will not warn you about.

Signature

Reply to this Message

Rate this thread:

Closures, Deferred Execution and IDisposable

Free Magazines