Barry said:
I agree with the general principle that constructors should not initiate
an operation that is costly in time or space, but I don't agree with the
notion that a constructor should delay 'full initialization with all
invariants holding' until a later 'Initialize' method is called. All
that does is complicate the interface, multiply the possible states,
etc. etc. I'm more interested in how you think the rationale behind the
guideline applies in this particular case.
My rationale is based on the fact that some FileStream constructors
acquire a resource in a complex manner. To me, opening a file, which
may require network activity, does not qualify as "minimal work".
Or to put it another way, I think there's a balance to be achieved -
described below.
There's always a balance. That's why I can't honestly say I'm too hung
up about it. There are other interface design problems in the BCL that
are more significant. And it's certainly possible that I'm
interpreting the guideline too strictly. But, it did come from people
who are smarter than I so I want to be cautious about ignoring it
altogether.
I can only talk about my personal experience using different classes. I
personally find FileStream nice and easy to work with, and I like its
idiom. On the other hand, I find System.Diagnostics.Process far more
awkward. I need to construct an instance, fiddle with various properties
before finally invoking a method.
Now, starting a process etc. is an expensive operation. As such, it
shouldn't occur inside the constructor. What's more, the various
subtleties and options on how one can create a process aren't fully
appreciated by people who are new to the functionality. With respect to
creating a process, I think the static method approach along with a
do-very-little constructor and tweakable properties works well - though
the static methods are missing in the current version of the BCL.
Thus, I think it's a question of where one draws the line. I think that
FileStream is good and that making it a tweakable stillborn object until
you finally call 'Open()' would be overkill. Just MHO.
I don't know. Even if Open were an instance method I'm not sure it
would seem overkill to me. Afterall, that's how a lot (most?) of the
classes in the BCL work. But, you're right, as it is, the FileStream
class works well.
I think it has more to do with the cost of the operation than the fact
that it may or may not throw exceptions.
Yeah, I mean the exceptions that a constructor throws should have
little impact on how the guideline is followed. I just think opening a
file is a potentially expensive and complex operation.
This is more an argument for named constructors, but I think that's an
orthogonal topic to throwing exceptions from constructors.
You're right. We could probably start a whole thread on that topic.
But these objects typically block for lengthy time periods. I would
agree to a rule of thumb that says "any operation that you might
consider making asynchronous doesn't belong in a constructor".
It's probably a bit too specific to include in any formal
documentation. But, it does sound reasonable to me.
