>The sample code shows one of the gazillion ways it's possible to cause an >object to be in an "illegal" (a.k.a. undefined or unexpected) state -- a >state that violates one or more "class invariants" (even if not formally >defined). Being exception-ignorant (whether inside the constructor or >elsewhere) is one way to do that. Software that allows objects to get into >undefined states (causing class invariants to be violated) -- in this case, >the "if all steps of object initialization are not complete, the object >should not be referenced by other objects" class invariant -- has bugs. >IMHO, there's nothing particularly special about this particular way of >causing a bug.
What state does an object whose constructor throws an exception need to guarantee that it is in? >The fact that an object exists during execution of its constructor is >pretty much a given -- otherwise you couldn't set properties of the object, >or call its methods, during the constructor. Constructor is a bad word. I agree with the person who commented on this thread about 'initialization'. The runtime manages construction on the managed heap all we do is conduct initialization in the 'constructor'. >The fact that an object exists until it's garbage collected (whether or not >an exception is raised in the constructor, or in any other method) is the >way things work in .NET. Sure. And the GC works to release objects for you when you no longer reference them. If you pass a reference to 'this' from a constructor that throws an exception then you're paving the way for a subtle (and possibly very problematic) bug to occur, and you've quite possibly created a memory leak. I think that my point was quite valid. >The fact that it's possible to store a reference to an object that is in an >illegal state, and thus prolong the lifetime of that "bad" object by >preventing an object from being GCd, doesn't surprise anyone -- does it? It might surprise someone who received an exception from a constructor and hadn't realised that even though the constructor didn't return a reference to the new object the object was still allocated on the heap. I'll admit to being surprised. >If you don't work carefully to avoid problems with an object's state being >internally inconsistent, you can cause objects with "bad state" to exist. >That's why it sometimes matters what order you write the lines of code in >your methods. What is new or different or surprising here? That's a pretty arrogant tone you've got there. And I thought I was arrogant. Pfft.. :) I have never had anyone warn me about passing a reference to 'this' from a constructor that might throw to another instance. I thought my point that the way InitializeComponent() is called first in a WinForms constructor and then proceeds to hook up event handlers before the rest of your code executes (even recommending that it is the first line in the constructor) was fairly insightful. Who knows what the WinForms architecture might then be doing to cause that reference to remain in scope even after initialization fails. Say an event on a static object is hooked for example? I'm pretty sure there heaps of bugs out in the world right now because someone failed to realise this (possibly even in the BCL, or WinForms architecture). I'm pretty sure that regardless of statements that indicate that 'dispose' is an 'optional' call there are parts of the WinForms architecture that rely on it, and if I can't get a reference to a constructed object yet the framework has one stashed in a delegate somewhere, then I've got a memory leak. What's the go with the Disposed event on Component by the way? Can you rely on this being raised? What happens if the component goes out of scope and gets finalized? Is Dispose a required call for Component? John. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
