🔒 Locked

Validating parameters in functions

Started by nervous pervous Oct 13, 2005 at 3:59 PM 7 replies 1.4k views

Original Post

Oct 13, 2005 at 3:59 PM

Hi, I was wondering which of the following methods is most commonly used when validating parameters for a function. Is there some guideline to follow? In my case, the parameters will be valid most of the time.

void myfunc(param)
{
  if(paramValidated) {
    //perform function
  } else {
    //set error flag
  }
}

void myfunc(param)
{
  if(paramValidated) {
    //perform function
    return;
  }

  //set error flag
}

void myfunc(param)
{
  if(!paramValidated) {
    //set error flag
    return;
  }

  //perform function
}

SiCrane

Oct 13, 2005 at 4:16 PM

The nature of parameter validation in functions depends on the nature of the parameters. For parameters whose values, if bad, indicate a severe logic error on the part of the programmer, convention in C and C++ is usually to use an assertion.

ex:

void myfunc(int param) {  assert( (param > 0) && (param <= 10) && "parameter must be from 1 to 10");}

This causes the program to halt execution at the point where the improper parameter value is detected while giving the point of failure and a diagnostic.

Now, in C++, upon detection of serious errors that are nonetheless not the result of programmer error, the error is often reported in terms of an exception. However, generally such error detection should be determined before the function is called, so on the function being called's side, would also generally be implemented in terms of an assertion. However, you may have instances where the parameter is technically valid, but not in a valid state, like a istream reference passed being a reference to a valid istream but the istream does not contain any data. In such a state, it might be wise to throw an exception at the top of the function being called. Generally, though validation of the state of objects received as parameters is done during the execution of the function body rather than as form of parameter validation.

In general, the concept of setting error flags is a bad one. Both error codes as return values are more robust. Unless your "error" is not an actual error, but a natural possible state. In that case a flag in an object's state may be warranted, such as stream objects setting eof flags.

EdR

Oct 13, 2005 at 4:19 PM

I may be wrong, so don't quote me, but I'm thinking they'd be more or less the same to the compiler, especially when optimized.

I would probably favor the last, because it puts the error trap at the top and I'd rather it there.

stylin

Oct 13, 2005 at 4:38 PM

You also have to be careful about deallocating any memory you may have allocated during execution of the function. Since you're not usually going to be checking all of the paramters simultaneously, and you may have additional error conditions you must deal with, your first method utilizing if() {} else {} is good since it allows you to properly free any memory you have allocated up to that point (and of course it works with nested ifs as well).

SiCrane

Oct 13, 2005 at 4:43 PM

Quote:
Original post by stylin
You also have to be careful about deallocating any memory you may have allocated during execution of the function.

Assuming C++ the use of RAII types should be preferred over explicit management of memory and resources.

nervous pervous

Oct 13, 2005 at 4:52 PM

Quote:
Original post by SiCrane
This causes the program to halt execution at the point where the improper parameter value is detected while giving the point of failure and a diagnostic.
.
.
.
In general, the concept of setting error flags is a bad one. Both error codes as return values are more robust.

The functions I'm writing are being exposed to the Python scripting language through a wrapper, so I need to handle invalid parameters more gracefully. I use error flags because some functions need to return values, but I guess I could return the value through a referenced parameter. Also, I need to validate the parameters inside the functions because the validation will depend on certain internal states. Basically my wrapper functions look like this:

PyObject* py_myfunc(){  //Parse parameters from python  clearErrorFlag();  myfunc(param);  if(errorFlagSet) {    //Raise python exception with error string  }    //Return some python object}

Would you mind explaining in more detail why the concept of error flags are bad? Is there something obviously wrong with what I am doing?

Anyway, thanks for all the advice so far!

frob

Oct 13, 2005 at 5:12 PM

Quote:
Original post by nervous pervous
Would you mind explaining in more detail why the concept of error flags are bad? Is there something obviously wrong with what I am doing?

Using them in conjunction with another mechanism might be acceptable (but probably not), for example, using the error flags for additional information

Relying on error flags exclusively is a problem.
Error flags are bad because they are seldom checked in practice.

Error return values are bad. Although they are checked a little more often than flags, they are not checked often enough. They can also cause problems if there is something legitimate to return. Generally you can return a status (not error code) if it isn't a critical problem.

Exceptions force you to either handle the error or propogate it. Since an invalid paramater is generally a critical problem, you should consider throwing an exception.

SiCrane

Oct 13, 2005 at 6:06 PM

In that case I suggest using proxy functions that you expose to Python. Have the proxy functions call the normal C/C++ functions, and raise a Python exception if the parameters have invalid values.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.