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.
Best way to exit a constructor
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:
[Edited by - skwee on September 25, 2010 2:31:52 PM]
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]
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.
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.
Author
Thanks guys I think I'll use throw. Most of the time it shouldn't matter but I'll generate a warning if it's used that way.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement