谈谈js参数合法性验证的事

有时为了让代码简单点，就忽略了参数的合法验证。说实话，谁都希望传来的参数都是合法的，毕竟检验参数是个很繁琐的事。作为给自己代码使用的程序， 照着自己的约定调用，当然也就不必检验了。如果是开发第三方插件或是类库的话，代码的健壮性就显得尤其重要了。用户在使用你的插件时经常出现莫名其妙的错 误，甚至是一些诡异的现象，就说明插件的异常处理工作没有到位。

      作为一个插件，用户可以传入任何类型任何范围的参数，不论他是有意还是无意的。如果是无意的错误，那么必须抛出描述这个错误的异常，让用户知道并能够及时改正，而不是无声无息的直接跳出方法。

      例如：

var Calendar = new function ()

{

var m_arrMonth =

[ "Jan" , "Feb" , "Mar" , "Apr" , "May" , "Jun" , "Jul" , "Aug" , "Sep" , "Oct" , "Nov" , "Dec" ];

this .getMonthName = function (n)

{

if (n<0 || n>11)

throw new Error( "无效的月份" );

return m_arrMonth[n];

};

};

      这样，当传入无效的月份数字后，错误就会抛出，开发者就可以及时发现数字上存在的错误。如果不验证或者换成直接返回，那么都将会得到一个undefined的值，并在以后的某个时期显示出来，就给调试添加了麻烦。

      其次，JS是个弱类型的语言，所以不仅要考虑参数范围这些逻辑问题，还得考虑参数的类型是否合法。如果是强类型语言，这个方法的参数直接指明是int（或 uint），那么在编译时只要是非数字类型的参数都无法通过。但是JS是个解释型的脚本，当然不会有这方面的检查了，这一些都需要自己来处理。显然，这里 我们可以简单的用isNaN来检查下参数类型：

view source print ?

var Calendar = new function ()

{

var m_arrMonth =

[ "Jan" , "Feb" , "Mar" , "Apr" , "May" , "Jun" , "Jul" , "Aug" , "Sep" , "Oct" , "Nov" , "Dec" ];

this .getMonthName = function (n)

{

if (isNaN(n))

throw new Error( "类型错误" );

if (n<0 || n>11)

throw new Error( "无效的月份" );

return m_arrMonth[n];

};

};

     如此一来，只有是数字，并且是规定范围内的数字，才能通过。但这样就绝对正确了吗？非也。错误就是这样在我们不经意间溜过去了。不多说，给个特定的参 数：2.5。他既是数字，也符合0-11的范围里，但返回的结果仍是undefined，原因很简单，数组下标不支持小数。因此还必须再加一步，数字取 整。

view source print ?

var Calendar = new function ()

{

var m_arrMonth =

[ "Jan" , "Feb" , "Mar" , "Apr" , "May" , "Jun" , "Jul" , "Aug" , "Sep" , "Oct" , "Nov" , "Dec" ];

this .getMonthName = function (n)

{

if (isNaN(n))

throw new Error( "类型错误" );

n >>= 0;

if (n<0 || n>11)

throw new Error( "无效的月份" );

return m_arrMonth[n];

};

};

      对于前两步，可以认为是对语言健壮性的扩充；最后步的的验证则是逻辑上的需要。举这个例子也是为了说明错误总是超出我们想象的，要做到完全严密的验证还得 考虑到各种各样的情况。当然，参数的验证也要有个度，尤其是object类型的参数，其中的存在着引用，那么就得根据实际情况而言了，过度的判断势必会影 响代码的效率。