Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!att!dptg!ulysses!andante!alice!garry
From: garry@alice.UUCP (garry hodgson)
Newsgroups: comp.lang.c++
Subject: Failed constructors ( Was Re: Failed allocation in constructors? )
Keywords: exception handling
Message-ID: <11061@alice.UUCP>
Date: 18 Jul 90 16:08:39 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 42

It seems to me that this discussion has gotten off track, or at least
off the track I'd hoped it would take.  The original question was,
"How do I deal with the case where a constructor fails?"  Note that
this does not necessarily mean the memory allocation failed.  Is there,
indeed, an elegant way to handle this?

An example from my own work:

I have a Connection class for doing IPC via sockets.  What I'd like to do
is something like:

	Connection *connection = new Connection( "kgbvax", PortNum );

	if ( connection )
		SendSecretDocuments( connection );
	else	ComplainLoudly();

Instead, what I do is:

	Connection *connection = new Connection( "kgbvax", PortNum );

	if ( connection->status() == GoAhead )
		SendSecretDocuments( connection );
	else	ComplainLoudly();

Admittedly, not a major difference in this example.  But conceptually,
I'd like to think that new Connection either gets me a connection to
another process, or fails in the attempt.  Having to check the state
of an object every time I create it seems rather...gasp...inelegant,
to say the least.

Anyone have a better way?

garry hodgson

PS	By the way, I think that discussing these kinds of issues, and alternate
	approaches/solutions to them, is a very effective use of this newsgroup.
	The recent discussions of C++ pros/cons have all pointed out that
	the major difficulty in effective C++ OO programming is making the paradigm
	shift to OOP.  This has also been my experience.  I find the discussion
	of "style" issues much more useful than some of the nuts & bolts stuff.
	Keep up the good work, folks.