In my PHP web applications I typically validate user input using custom functions which return either NULL if the input does not match the validation criteria, or return the original input value if the validation criteria are satisfied. So a basic process flow would look something like this:
$user_input = $_POST['fieldname'];
$user_input = validation_function($user_input);
if (isset($user_input)) {
// do stuff
}
The nice thing about this is that I can take any number of user inputs, validate them, and then stick them into the isset()
function as parameters, since the isset()
function takes a variable number of parameters.
Now, I've been reading a lot about how NULL returns are bad, and this SO question, "Is returning null bad design?" has a great answer, basically stating that "The rationale behind not returning null is that you do not have to check for it and hence your code does not need to follow a different path based on the return value". I understand how this is beneficial in the internal workings of an application, but how can this principle be applied to input validation?
The crux of the question is, how do I handle input validation in a way that I do not have to return NULL like in the code example I provided above?