Add validation tests for all functions.

[revarbat]

All functions should have validation tests.

[RonaldoCMP]

I have included parameter validation tests on every API function and module of a library I am working on. To simplify the task, I have written another file (checks.scad) to be used by the API file including a bunch of test functions like:

function is_3Dvec(v) = (0*v==[0,0,0]);
function is_numlist(l,n) = is_list(l) && (is_undef(n) || n==len(l) ) && _and([for(v=l) is_num(v) ]);
function _and(cond) = [for(c=cond) if(!c) 0]==[];

Besides, checks.dat has 3 main functions to issue console error, warns and info messages like:

function assert_msg(org, msg ) = ...
function warn_msg(org, msg) =...
function info_msg(org, msg, id=0) = ...

assert_msg() is the base of parameter validation. The parameter org is a string containing the caller name. In warn_msg() and info_msg(), the parameter msg is a simple string. In assert_msg(), the msg parameter is a list with one element for each caller function parameter and where each element in the list is a pair of a boolean value and a string. A typical usage is:

function add2vectors(v1, v2) =
let( assert_msg( "add2vectors",
[ [is_numlist(v1) , "a list of numbers"],
[is_numlist(v2,len(v1)), "a list of numbers with the same dimension of the first"] ] ) )
v1+v2;

The result of

add= add2vectors([0,0], [0,1,0])

would be the console message:

ERROR in function add2vectors:
2nd param. isn't a list of numbers with the same dimension of the first

ERROR: Assertion '_and(x)' failed in file checks.scad, line 37

Hope it helps.

[RonaldoCMP]

I suggest that we seek for a standardization of error messages to easy the user's task of identifying his/her error in the args. I have been trying to do it but it is already inconsistent. I have found many different styles of error message.

Some questions to consider:

• Should the error msg indicate the name of the function which detected the error? As we don't have a central error report, the native assert msg and its details may be considered enough to identify its origin. The function name may not be enough because it might be called in many places of the user's code. So, the user would need to read the assert msg anyway to identify the code line.
• Should the msg indicates what is wrong or what it is expected? I see pros and cons in each alternative.
• Should the message include the value of the offending arg? That may generate large amounts of text depending on the arg value. To specify the offending value in a long array, for instance, may require extra awkward code.
• In some cases, the arg validation may be left to another function that would be called anyway in the normal flow. Would be that reasonable for the user? The error msg would come from a function the user's code doesn't called directly.

[adrianVmariano]

Basically duplicate of #231