3

Is there a way to stop a C++ class if there is an error in the instantiation? Like, return NULL maybe? Basically I have a wrapper class for MySQL, and the constructor does the connecting, but if the connection fails, I want the object to be, um, useless?

PDB::PDB(string _DB_IP, string _DB_USER, string _DB_PASS, string _DB_DB) : _DB_IP( _DB_IP ), _DB_USER( _DB_USER ), _DB_PASS( _DB_PASS ), _DB_DB( _DB_DB ) { mysql_init(&this->mysql); this->connection = mysql_real_connect(&this->mysql, this->_DB_IP.c_str(), this->_DB_USER.c_str(), this->_DB_PASS.c_str(), this->_DB_DB.c_str(), 0, 0, 0); if( this->connection == NULL ) // WHAT SHOULD I DO HERE, OTHER THAN THROW AN ERROR? { cout << mysql_error(&this->mysql) << endl; } this->result = NULL; }

What should I do in the NULL test, to stop creation, etc?

Improve this question
2
  • Maybe I should move the connection out of the construct? Or throw an error in the query function if this->connection is null? Hmmmz Commented Dec 17, 2010 at 23:01
  • 7
    This is a good slogan to put on a t-shirt. Commented Dec 17, 2010 at 23:01

2 Answers 2

Reset to default
10

Throwing an exception is really the only way to indicate an error during construction.

http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.8

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Um, no it is not. A std::fstream object does not indicate errors in that way, for example.
Because std::fstream doesn't indicate errors in the constructor.
@unquiet mind: Yes, this is an example of the "zombie" technique mentioned in the linked article. There may be times when it's the "least bad" alternative, as Marshall Cline says, but you'd have to present a pretty good argument to convince me it's better than throwing.
@Fred I think a good argument FOR FILE STREAMS is that the Standard Library does it that way and it works pretty well. I think it is much easier to work with such streams rather than ones that throw exceptions.
@unquiet mind: actually often IO errors go unnoticed (especially by novices, who don't understand why their code go in an infinite loop if the input is ill-formed) because iostream by default doesn't throw any error.
5

If the connection can normally fail, set a flag in the object and provide an is_connected() member function for the class, and use it in your application code. If it normally cannot fail, throw an exception. The former is the pattern that the C++ Standard Library uses for opening file streams.

Improve this answer

4 Comments

Beware of explanations using terms (without defining them) like "normally" or "exceptional circumstances" (these two terms are opposites of each other) to describe exception use. The above text can be read to support either position of using exceptions or not (depending on readers' existing preference for both exception use and what is "normal"), so it really doesn't help answer the question.
@Fred It does answer the question - sometimes you use exceptions, and sometimes you don't.
It is also worth mentioning that exceptions aren't very portable, especially across library boundaries. The Mozilla C++ Portability Guide outright prohibits use of exceptions, for example. So sometimes the only alternative you have is that isValid flag no matter if it's "normal" or "exceptional curcumstances".
How does "sometimes you use exceptions, and sometimes you don't" help? The obvious response to that is "duh, that's why I asked," because it just restates the question. Given "would you like tea or coffee?", a syntactically valid answer is "yes", but it's still not helpful for essentially the same reasons I point out above.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.