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

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

      例如：

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来检查下参数类型：

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，原因很简单，数组下标不支持小数。因此还必须再加一步，数字取整。

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类型的参数，其中的存在着引用，那么就得根据实际情况而言了，过度的判断势必会影响代码的效率。

作者: EtherDream 发表于 2011-03-07 18:57 原文链接

关键字 谈谈js参数合法性验证的事
推荐.NET配套的通用数据层ORM框架：CYQ.Data 通用数据层框架