对于公有的方法，要用Javadoc的@throws标签（tag）在文档中说明违反参数值限制时会抛出的异常。这样的异常通常为IllegalArgumentException、IndexOutOfBoundsException或NullPointerException。一旦在文档中记录了对于方法参数的限制，并且记录了一旦违反这些限制将要抛出的异常，强加这些限制就是非常简单地事情了。
对于未被导出的方法（unexported method），作为包的创建者，你可以控制这个方法将在哪些情况下被调用，因此你可以，也应该确保只将有效地参数值传递进来。因此，非公有的方法通常应该使用断言（assertion）来检查他们的参数。
从本质上讲，这些断言是在声称被断言的条件将会为真，无论外围包的客户端如何使用它。不同于一般的有效性检查，断言如果失败，将会抛出AssertionError。也不同于一般的有效性检查，如果他们没有起到作用，本质上也不会有成本开销，除非通过将-ea（或者-enableassertions）标记（flag）传递给Java解释器，来启用他们。
对于有些参数，方法本身没有用到，却被保存起来供以后使用，检验这类参数的有效性尤为重要。
如前所述，有些参数被方法保存起来供以后使用，构造器正是代表了这种原则的一种特殊情形。检查构造器参数的有效性是非常重要的，这样可以避免构造出来的对象违反了这个类的约束条件。
在方法执行他的计算任务之前，应该先检查他的参数，这一规则也有例外。一个很重要的例外是，在有些情况下，有效性检查工作非常昂贵，或者根本是不切实际的，而且有效性检查已隐含在计算过程中完成。
有时候，某些计算会隐式的执行必要的有效性检查，但是如果检查不成功，就会抛出错误的异常。换句话说，由于无效的参数值而导致计算过程抛出的异常，与文档中标明这个方法将抛出的异常并不相符。在这种情况下，应该使用异常转译（exception translation）技术，将计算过程中抛出的异常转换为正确的异常。
不要从本文的内容中得出这样的结论：对参数的任何限制都是件好事。相反，在设计方法时，应该使他们尽可能的通用，并符合实际的需要。假如方法对于他能接受的所有参数值都能够完成合理的工作，对参数的限制就应该是越少越好。然而，通常情况下，有些限制对于被实现的抽象来说是固定的。
简而言之，每当编写方法或者构造器的时候，应该考虑他的参数有哪些限制。应该把这些限制写到文档中，并且在这个方法体的开头处，通过显式的检查来实施这些限制。养成这样的习惯是非常重要的。只要有效性检查有一次失败，你为必要的有效性检查所付出的努力便都可以连本带利的得到偿还了。