Could anybody tell me where to find the answers to the following questions:

Explain what happens when an exception is thrown in C++.

What happens if an exception is throws from an object's constructor?

What happens if an exception is throws from an object's destructor?

When would you choose to return an error code rather than throw an exception?

Maybe Google?

__________________

Cow: You're a lawyer too?
Mooseblood (mosquito): Ma'am, I was already a bloodsucking parasite. All I needed was a briefcase!

The installed unwind handler unwinds the exception.


ctors are not allowed to throw an exception. In other words, we promise that the ctor will succeed. That is the contract.


The unwind handler is invoked. Resources allocated by the object are not released unless there is some kind of smart unwind handler installed that has some advanced knowledge of the class(es).


It is arguable that one should NEVER throw an exception. What is the difference between a goto and a throw?

Returning an error code in C++ assumes that someone will check it and do something meaningful as a result of it. Contract programming in C++ says that we succeed or we throw an exception. Return codes are the world of C programming. If you want to carry them into C++, that's your choice. The preferred choice is probably to use interfaces that interact with objects designed to deal with problems using behavioral specifications appropriate to the use-cases associated with your domain requirements.

Of course, C++ will allow you to do anything that compiles. Whether you choose to do things arguably "right" or not is up to you. Every day I see cases of inheritance for convenience, bad relationships, worse code and stupid or no comments...just to name a few. Oh yeah. I've seen all data public, declarations in one file being modified by another file ad nauseum to the point that you really never know who's modifying the data nor can you possibly utilize synchronization intrinsycs to protect it...

Alternatively, you can always google it, as C++ master WaltP suggests...so much for a help forum. I guess that you have to keep pounding away at your cumulative number of posts so that others think that you have a clue...in fact, that is how one obtains the dubious title of "a name known to all."


:davis:

That is false. It is destructors that promise not to throw exceptions, not constructors. Actually, constructors are a very good example of when you can't return an error code, and need an exception.

It is perfectly acceptable for an object's constructor to throw an exception, and I can't imagine why you would think otherwise. Of course, in case up to the point you throw the exception your code allocates memory or locks resources, you will need to handle this, as the destructor won't get called. If you want to avoid this scenario and make a contract with the users of your class not to throw an exception from the constructor, that is your business; the C++ exception model makes no such promise. You should expect and be prepared for an object to throw an exception when building it, unless the creator of the class documented the constructor to "not throw". Obviously, it would be ideal for developers to document the "throw" cases as well, with the complete list of exception types a function may throw, but I'm a dreamer.

You should NOT throw an exception from an object's destructor, because it may be called during the stack unwinding process of another exception. So while the local objects on the stack are getting destroyed, one of them decides (through its destructor) to throw another exception, thus needing to start its own unwinding process until it reaches its catch handler. So what's a poor runtime to do?


Now was that really necessary!? Enough with the ad-hominem attacks, already... There is such a thing as decent discourse even in an informal environment like the Internet. I would expect people past their 20's to show a more respectful attitude than a person my age.

__________________
Please read these Guidelines before posting on the forum

"A person who never made a mistake never tried anything new."
Einstein

You're welcome to disagree if you want. The idea of a ctor is that is always succeeds to construct the object. Sure, throw an exception if it will fail...however, it is better to design ctors so that they never fail.

It is too obvious that they can't return an error code (at least in the no-args version).

Also, if your ctor allocates something prior to throwing an exception, your dtor won't be called, leaving a mess behind. Therefore, the best way to design a class is so that the ctor never fails. It isn't impossible, but sometimes it is impractical.

It is better to start with the position that ctors don't throw. You may disagree if you want. Perhaps you are reading my "not allowed" too literally AND not considering that I'm saying it in the context of contract programming. Of course, the contract is that whenever we are unable to succeed in fulfilling the contract, we throw. Therefore, ctors OBVIOUSLY "can" throw, rather they should NOT throw. Offering them up as a perfectly good reason to be throwing leaves out the importance of quality design reasoning. OTOH, perhaps my way of saying my side of this "argument" is too strict and less informative?

For anyone new to C++, there are nearly as many cases for exceptions within "the rules" of quality coding as there are rules. If you want to code better, avoid things like throwing fromctors. Figure out an alternative way to create your class so that it NEVER fails in the ctor.


:davis: