Re: undef and empty variables

It is my understanding that undef always becomes NULL, and that the handling of “an empty string” may vary. (Database drivers tend to try to second-guess that situation, and the outcome is typically not that bad ...)

Nevertheless, bear in mind that, in an array, undef is “a value.” The slot is occupied, although the value in that slot may be undef.

Replies are listed 'Best First'.
Re^2: undef and empty variables by locked_user sundialsvc4 (Abbot) on Jan 20, 2011 at 15:11 UTC
Thinking further about exactly how I would write this ... I would pass a hashref containing the parameter values, to a `sub` that would perform the query. The SQL string would use placeholders, and the corresponding array of parameter-values would contain expressions that pulled keys from the hashref ... by name. Any non-existent key would produce `undef` automagically. My `sub` would also contain error checks. If the hashref was supposed to contain certain keys and perhaps to have non-empty values for those keys, my routine would expressly check for this and would `croak` if something was not right. (Thus, “the fact that the program did not `croak`” tells me positively that the error condition I was testing for does not exist ... “therefore, the bug must be somewhere else.”) The code would go straight into production with those error-checks in place.

Replies are listed 'Best First'.

Re^2: undef and empty variables
by locked_user sundialsvc4 (Abbot) on Jan 20, 2011 at 15:11 UTC

Thinking further about exactly how I would write this ... I would pass a hashref containing the parameter values, to a sub that would perform the query. The SQL string would use placeholders, and the corresponding array of parameter-values would contain expressions that pulled keys from the hashref ... by name. Any non-existent key would produce undef automagically.

My sub would also contain error checks. If the hashref was supposed to contain certain keys and perhaps to have non-empty values for those keys, my routine would expressly check for this and would croak if something was not right. (Thus, “the fact that the program did not croak” tells me positively that the error condition I was testing for does not exist ... “therefore, the bug must be somewhere else.”) The code would go straight into production with those error-checks in place.