Sign in to follow this  
wookie1

Best way to exit a constructor

Recommended Posts

I read a post which suggested avoiding the use of singletons by putting an assert inside the constructor which checks a static bool of whether there is already an instance. I liked this idea but as far as I know assert is used much more for debugging code and then a global ndbug is made for release builds. Hence I don't really want to bastardize the use of assert and make it less useful elsewhere. Looking into the idea further it seems I have three more choices. I can use abort, exit or throw an exception.
I'm not sure if throw would clean up properly after itself and think I would rather write a message to file or console than putting try catch all over my code.
Abort doesn't appear to clean up properly. So I'm leaning towards writing an error message then calling exit.
Any advice.

Share this post


Link to post
Share on other sites
I'd suggest you not to use singletons at all. They introduce a global state that is not visible without examining your code. They couple your classes without any purpose, and they violate the single responsibility principle.

As regard to your question, the most proper way to terminate a constructor, is to throw exception. Since constructor have no return values, you only can throw an exception.
An uglier way is to hold some internal boolean member like status, that will be initialized to true if constructor did what is suppose to do, without errors, and false otherwise. Then your code will look like:

Foo f;
if(!f.Created()){
//do something bad
}




[Edited by - skwee on September 25, 2010 2:31:52 PM]

Share this post


Link to post
Share on other sites
Let's assume for the sake of argument that you actually have a rare honest-to-god singleton situation, and you aren't just using it to pretend you don't have any global variables.

In such a situation, an assertion would be my chosen approach, for the following reasons:

* While throwing an exception is the normal way to fail out of a constructor, exceptions are not useful if there's nothing you could do to recover from the situation. From the other options you've listed, it looks like this typifies your situation, but let me know if I've misread.

* exit() will allow some amount of cleanup before it exits. This is why you should avoid using it here. When you run into a wholly unexpected situation (as opposed to an unfortunate but conceivable situation), you have to start treading very lightly if you want to do anything useful in your last few moments of life. An unconsidered function call could result in dying from a segfault or other error, squandering your opportunity to diagnose the error. Likewise, freeing up resources could cause a multiple deletion or similar error. Write your log, then die. The OS will wipe up your handles for you.

* abort() almost fits. However, because it's such an inconceivable situation that you would consider killing the program if it ever happened, theoretically the only time you'd ever run into it is during development/testing. The one exception to this is if you feel that printing a useful message to the end user and then dying suddenly would be preferable to continuing and putting the program on a death march that could confuse end-user debugging attempts or corrupt data or something.

* assert() is generally the right thing to do in a video game when something inconceivable happens. It allows you to find problems during testing, and in shipped builds it allows you to ignore the situation and hope for the best.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this