Thread: Is there a standard way to check if struct member is uninitialized?

Originally Posted by whiteflags

Technically you're supposed to use the STL with exceptions in mind. main() could look like this:

Code:

try {
   vector<string> elements;
   elements.push_back(string("one"));
   elements.push_back(string("two"));
   elements.push_back(string("three"));
   
   // code ...
}
catch (bad_alloc &loadError)
{
   cerr << loadError.what() << endl;
   return 0;
}
// other catches

// no-fail code here
return 0; 

// verily, return 0 is guaranteed to work ;)

The moral: If you are writing a library, you need to provide documentation of your exceptions, so that people who use it (including yourself) will know what to catch. It is the user's responsibility to write this kind of code, not the supplier's.

Maybe...but how do you throw exceptions from/inside a class object to a catch(er) in int main() ? Are the exceptions automatically visisble to main()?

Originally Posted by whiteflags

Ah, well exception's unwind the call stack.

So if you end up throwing an exception, from push_back() it might be caught where push_back() was used. If not there, then in the function that called that function, even if it was an object method. If not in the object method, then the object is destroyed when it has to go further into the call stack... until ultimately, main(). Now, either main() catches the exception or the program terminates badly with what's called an unhandled exception.

Would it be considered bad coding style to throw and catch the object's own exceptions inside the object's member functions anyway? That way, int main() does not have to catch any exceptions (or at least, not from my library)?

So writing exception safe classes is important for the users of your class: your class should always meet one of the guarantees elaborated on by the link I put. And you should make sure that you have a working destructor so that the call stack unwinding does not leak your object's memory.

How does it do that?
And what would I need to destroy other than "new" objects of my class (which I don't have any of, at this time anyway) in my destructor?
I read the whole link you gave me (which, btw, confirmed to me that I should throw an exception for a failed getAttr), but it doesn't answer that question.

Originally Posted by Programmer_P

Would it be considered bad coding style to throw and catch the object's own exceptions inside the object's member functions anyway? That way, int main() does not have to catch any exceptions (or at least, not from my library)?

You should not, unless it is something your library can handle.
If you need something cleaned up, make sure that that which needs cleaning up resides inside a class whose destructor will clean it up.
Exceptions should get propagated, so usually there is no need to catch them unless you need to handle them there and them.
And your library should not terminate your program, in any circumstances. It should propagate the error and your programer, the caller, the user, should handle them and gracefully exit if something goes wrong.