On (17 Aug 97) Chris Downs wrote to Jerry Coffin...
 JC> exception handling was invented largely to deal with errors in
 JC> ctors.
 CD>  That seems a tab broad.  Exceptions were designed to handle any sort
 CD> of errors.
That's true, but _The Design and Evolution of C++_ has a section in its
chapter on exception handling that seems to imply that the ctor problem
was one of the primary reasons it was added.
I'd note that exception handling has been one of the most controversial
and difficult features of C++ to implement.  The committee spent roughly
a year debating the general idea of how exception handling should work
(particularly whether you should be able to resume after an exception or
not.)  It's also one of the few new features that violates the dictum
that you shouldn't pay for things you don't use: there's nearly always
at least some price in size or speed, or most often both, merely for
enabling exception handling, even if an exception is never thrown.
In short, exception handling has significant shortcomings, and would
likely NOT have been added to C++ had reasonable alternatives existed in
all situations.  However, there's basically NO other way of handling
problems in ctors without totally redesiging the entire language.
 JC> It's nearly inevitable that if you require a separate call to
 JC> initialize the class that at least occassionally somebody will
 JC> forget to call it.  One of the major strengths of C++ is its ability
 JC> to ctors and ensure that as soon as an object comes into existence,
 JC> it WILL be initialized.  Separating the two cripples this capability.
 CD>  That would depend upon how it's implemented.  As you know, MFC
 CD> heavily relies upon the separate contruction/initialization paradigm
 CD> and I don't see how this "cripples" it.
Note that I said it cripples the capability, not that it cripples all
associated code.  Nonetheless, I think MFC (and OWL, for that matter)
would be better if they eliminated this wart.  Oddly enough, there's
quite a simple method available for doing so, but few (if any) app
frameworks use it.
To some extent this is less important in a full-blown framework than in
a relatively small, more or less standalone class.  As you know, much of
the time, both the ctor an initializer for a class in either MFC or OWL
is called by other code in the framework rather than by the user.
In fact, most programmers never need to worry about the ctor at all.
Rather than really requiring two-step initialization, this merely uses a
different name for the initialization.
Despite these mitigating circumstances, I still believe that MFC,
OWL, and other such frameworks would be better off if they worked harder
at doing initialization in one step.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------