-
November 9th, 2010, 10:04 AM
#1
error checking question
say i have a class which the user can make an object of by passing in 2 parameters. If the parameters entered are wrong how should i handle this?
1.) should i try to create the object,and then do the checking in the constructor? if the arguments are invalid then should i cancel creation(if possible) or set the arguments to a dummy value(for example all -1 for int variables and all "zzzzz" for string variables?
2.) should i check the user arguments before the creation of the class begins? for example.
if (validArguments)
{
//create object
}
else
{
//do not create the object
}
the statement in number 2 seems reasonable to me,but what if i make a class that i want to publish for others to use. I i used solution number 2. I would have no error checking for my class! and user's would have to make their own error checking functions for it.
if i choose statement number 1(which would make my class better because it has built in error checking) i have no idea how to deal with the invalid data.
any suggestions would be greatly appreciated. -thx
-
November 9th, 2010, 10:17 AM
#2
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).
-
November 9th, 2010, 11:33 AM
#3
Re: error checking question
I tend to use (2), as a failure in our applications usually means a serious programming error.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
November 10th, 2010, 01:33 PM
#4
Re: error checking question
I would also throw an exception.
-
November 10th, 2010, 02:23 PM
#5
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.
-
November 10th, 2010, 02:26 PM
#6
Re: error checking question
Get Microsoft Visual C++ Express here or CodeBlocks here.
Get STLFilt here to radically improve error messages when using the STL.
Get these two can't live without C++ libraries, BOOST here and Loki here.
Check your code with the Comeau Compiler and FlexeLint for standards compliance and some subtle errors.
Always use [code] code tags [/code] to make code legible and preserve indentation.
Do not ask for help writing destructive software such as viruses, gamehacks, keyloggers and the suchlike.
-
November 11th, 2010, 12:46 PM
#7
Re: error checking question
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.
-
November 11th, 2010, 01:32 PM
#8
Re: error checking question
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.
Is your question related to IO?
Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.
-
November 11th, 2010, 03:05 PM
#9
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.
-
November 11th, 2010, 04:41 PM
#10
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.
Is your question related to IO?
Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.
-
November 12th, 2010, 11:55 AM
#11
Re: error checking question
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.
-
November 12th, 2010, 12:05 PM
#12
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.
-
November 12th, 2010, 01:49 PM
#13
Re: error checking question
-
November 12th, 2010, 02:44 PM
#14
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());
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|