.NET

Why No Dispose Event?

Pete Vidler — Mon, 20 Oct 2003 17:32:00 GMT

We all know about resource management in .NET (and Windows Form in particular). I'm talking about using, IDisposable, etc. These constructs work well when you own all the objects that you keep references to, as you simply dispose of each of them from your own Dispose method.

But what if you have an object that wraps another object (similar to the decorator pattern)? A Decorator must contain a reference to a ConcreteComponent, but what happens when the ConcreteComponent must be Disposed? Surely we would want Decorator's lifetime to be tied to that of ConcreteComponent? How does Decorator get disposed? There wouldn't be a problem if we could guarantee that Dispose would be called on Decorator, but what if we want to be able to remove the Decorator and keep the ConcreteComponent alive?

If we had a "Dispose" event, Decorator could just handle it and dispose of itself when necessary. But we don't. Why not -- we have events for everything else don't we?

As a more concrete example, consider my recent posting about Tablet PC support. It's quite easy to derive from Panel and add Inking to it, but it's not so easy to add that support from outside the class. In order to do this you could write a separate class (which will contain the InkOverlay) and pass a Panel object to it's constructor (like in decorator). The problem here is that, from my new class I have no way of knowing when Panel has been disposed of -- which would be nice as the InkOverlay object implements IDisposable itself.

Syntax Colouring of Posted Code

Pete Vidler — Sat, 18 Oct 2003 15:04:00 GMT

In case anyone was wondering, I've been using Jeff Key's excellent SnippetCompiler to write all the code in this blog. The big advantage with this approach is that I can just select "Export->Html Page..." and copy-paste the resulting HTML.

Exceptions

Pete Vidler — Tue, 14 Oct 2003 18:18:00 GMT

Looks like it's the season for talking about exceptions. Brad Abrams discusses them at some length, and now Joel Spolsky does the same (and with almost the exact opposite opinion).

I seem to be cursed with the ability to see both sides of this issue. On the one hand, I like being able to throw an exception whenever an impossible condition comes up in running code (you know, when that if-statement you put in "just in case" goes off completely unexpectedly). On the other hand, I hate having to deal with exceptions being thrown... trying to make my code completely exception safe is very annoying.

And there's nothing exceptional about calling File.Open with a non-existent file.