Re: error checking question
There are three primary means of dealing with invalid object creation:
1) If the constructor parameters are invalid, place the object into an invalid state which can be queried. This is essentially how istreams and ostreams work.
2) If the constructor parameters are invalid, throw an exception.
3) Require the constructor to be unfailable, and initialize the object with a later method call which is capable of returning true or false.
Clearly, both (1) and (3) require the object to have some flag indicating if the object has yet been initialized. Personally I like (1), but some people prefer (2).
Re: error checking question
I tend to use (2), as a failure in our applications usually means a serious programming error.
Re: error checking question
I would also throw an exception.
Re: error checking question
If it's the function that's creating the object, you could make it return a bool indicating success or failure, or a pointer to the object it created, with a NULL indicating failure.
Re: error checking question
Re: error checking question
Quote:
Originally Posted by
lochnessmonster
2.) should i check the user arguments before the creation of the class begins?
I think you should also do this. Any data coming from outside your program, such as user input, should be checked at the first possible opportunity.
Re: error checking question
Quote:
Originally Posted by
Zaccheus
I think you should also do this. Any data coming from outside your program, such as user input, should be checked at the first possible opportunity.
Why stop at data from outside the program? Check everything. The final result might be a bit slower, but have much less bugs. Worst case scenario, you can have debug-only checks.
Re: error checking question
Don't think the 'check everything' is practicable. The problem is not so much the check itself but the error handling. If wrong input arguments are given you normally have only the choice to stop the execution or to correct the input values in the function itself and go on. In the first case you could try to produce a core dump which would give a developer a chance to find and correct the issue. If you only make an error logging and abort it normally is impossible to find out what happened if you can't reproduce the error in the developer's environment. Moreover, if the programs runs at the customer's site, it is commonly not acceptable that it crashes for minor reasons, i. e. the customer will accept an error message and probably will report the errors but he won't accept data losses or incomplete processing.
Handling the errors by a message and correcting the input values is even more questionable. If the correcting measures work, the errors probably will never fixed and often the developers won't even get informed that something goes wrong. I even experienced cases where the internal corrections couldn't be removed cause that would/might change the behavior of the program.
So in my opinion the only good way is to test the majority of all functions with all possible input values by automated test cases. If a function has passed all those tests it doesn't need extra checks on all arguments but only basic checks, e. g. for NULL pointers or division by zero. In those cases the program has to exit and say sorry. But all other cases should be tested before and debug assertions is a further good means to reach that goal.
Re: error checking question
There are 2 kinds of invalid input: Input from user, and the kind that only happens when a programming error occurs. Bad input from user should be supported in some way (fixed, or reported as invalid). Bad input from bad programming... Well at best you'd like to detect it.
I agree with everything you said, but in the real world, it is not possible to run batteries of test to check each and every function with each and every input. You can check every usecase, but not every individual function. Besides, how can those tests work if said functions don't check there input to notify you?
In particular, what do you do with functions that only work with something like "my input shall be a number from 0 to 10". Checking the function "works" with 15 would be pointless (it can't), yet you do want to check if somebody out there isn't calling your function with 15. And the only way to do that is by having code at the beginning of your function that tests input. Either that or pray (and I'm not a believer).
Of course, how you deal with invalid input when you encounter it is a whole other problem, and I agree that not everything is acceptable in every situation.
Re: error checking question
Quote:
Originally Posted by
monarch_dodra
Why stop at data from outside the program? Check everything. The final result might be a bit slower, but have much less bugs. Worst case scenario, you can have debug-only checks.
I would suggest checking the input values of public functions. Private functions should never get invalid input.
Re: error checking question
Never *should*, but sometimes do. It doesn't hurt to throw some assert()s in there, they'll be removed for release builds anyway.
Re: error checking question
Re: error checking question
One trick I use for checking complex conditions that won't easily fit into an assert() is something like:
Code:
bool checkConsistent() { ... }
...
assert(checkConsistent());