Validate input parameters before pass to the function or in function body?

[akash16]

Hi All,

Validate input parameters before pass to the function or in function body?

e.g. in bellow example which is the best practice CASE 1 or CASE 2?

I usually follow the CASE 1 and validate input parameters value before pass them to the function. to avoid unnecessary function call in case of incorrect input parameters.

callFun()
{
  int a;
  string str;
  // CASE 1:: 
  // Validate input parameters a / str here before pass them to the function fun
  fun(a, str)
}
fun(int a, string str)
{
  // CASE 2::
  // Validate input parameters a / str here before refer them further

}

[againtry]

In the interests of re-usability especially, but not only, the principles of design by contract DBC have a great deal of merit.

This means that effectively both cases apply and it is a matter for the caller to satisfy the functions pre conditions upon which the function must satisfy its post conditions (read obligation to the caller)

You have to check you are sending an int and string with whatever constraints, and the function undertakes whatever it is supposed to do reliably.

https://en.wikipedia.org/wiki/Design_by_contract

[Aaron Vienneau]

Hi Akash,

Good question. In addition to the above, as you start to work with code (and input) that isn't just your own, the concept of function "pre-conditions" and "post-conditions" becomes a bit more apparent and practical. When it's all just your own code, that can easily be changed, the concepts seem a bit foreign.

Consider a case where you're going to use a library called "Temperature" written by Againtry. It might supply a function in its interface that converts Fahrenheit to Celsius, like so:

float Fahrenheit_To_Celsius(float f);

You likely have very little idea about how that function is implemented (and you're not responsible for any verification that goes on within it), but Againtry has made a type of agreement with you: "If you give me a float that represents a valid Fahrenheit, I will give you back the same temperature in Celsius".

The functions "Pre-condition" is: Fahrenheit_To_Celsius expects a valid float that represents a Fahrenheit.

The functions "Post-condition" is: Fahrenheit_To_Celsius will return a valid float that represents the same temperature in Celcius, if it's Pre-condition is satisfied

With all of that said: Say your fahrenheit input is coming from some end-user -- then it's your job to make sure that you verify the user's input before calling Fahrenheit_To_Celsius so that it receives the correct input to satisfy its pre-condition and it's Againtrys job to make sure that he does the conversion properly and returns a correct value.

It's a trite example, and maybe not precisely all of the things in the above Wiki, but realizing that not all code is going to be your own is sometimes a concept that eludes people who are beginning.

EDIT: It's also worth noting that, at some point, the creator of code has to assume some sort of sanity on the caller's part, given a clear enough interface. If you try to solve every single verification case, your code quickly becomes hard to decipher. So, in this case Againtry will probably not do many checks in his function besides maybe a bounds check, he's going to write the function assuming the caller has some type of sanity and is calling it with the correct pre-condition met.

Hope that helped.

[Doraonroids]

I was always told to test inside of functions and handle the incorrect values properly. That is because when we create objects and need to use them in multiple projects or peers to use they shouldn't have to test inputs before sending them to a function. Rather we are told to create error cases to show how the function was used wrong.

We were told this saves time when someone else wants to implement your objects without vigorous documentation reading.

Provided you tell them that the function has to take in an integer and a string in your case. My professor would want to be able to enter any possible string and any possible integer combination. He assumes users understand int and string have limitations.

[jonnin]

I agree with the above. Typically I have a small handful of extremely common validation functions that I reuse, for example, 'is int in this range' or 'is this ascii string printable' and so on. Many times you need something more specific, but you will find you are doing the same things over and over. But I call the reusable validations inside the method that needs them validated.

But, the method that needs them validated for me is 'usually' only the input routine.

OOP really helps here. Your private members have setter functions, because you want to validate them. The setter does the validation. The class can use them without validation, possibly calling many, many functions without worry because the data is known-good! This model is simple, but very powerful if you are, as you said, looking to avoid calling functions when you don't have valid data (can't happen in this model, the data is known-good everywhere once you get past the user input stage which blocks bad data), and the validation only happens once no matter how many times you use the same data.