Question

在 Java 中，对那些要调用方法的客户程序员，我们要通知他们可能从自己的方法里“掷”出违例。这是一种有礼貌的做法，只有它才能使客户程序员准确地知道要编写什么代码来捕获所有潜在的违例。当然，若你同时提供了源码，客户程序员甚至能全盘检查代码，找出相应的 throw 语句。但尽管如此，通常并不随同源码提供库。为解决这个问题，Java 提供了一种特殊的语法格式（并强迫我们采用），以便礼貌地告诉客户程序员该方法会“掷”出什么违例，令对方方便地加以控制。这便是我们在这里要讲述的“违例规范”，它属于方法声明的一部分，位于自变量（参数）列表的后面。

违例规范采用了一个额外的关键字：throws；后面跟随全部潜在的违例类型。因此，我们的方法定义看起来应象下面这个样子：

void f() throws tooBig, tooSmall, divZero { //...

若使用下述代码：

void f() [ // ...

它意味着不会从方法里“掷”出违例（除类型为 RuntimeException 的违例以外，它可能从任何地方掷出——稍后还会详细讲述）。

但不能完全依赖违例规范——假若方法造成了一个违例，但没有对其进行控制，编译器会侦测到这个情况，并告诉我们必须控制违例，或者指出应该从方法里“掷”出一个违例规范。通过坚持从顶部到底部排列违例规范，Java 可在编译期保证违例的正确性（注释②）。

②：这是在 C++违例控制基础上一个显著的进步，后者除非到运行期，否则不会捕获不符合违例规范的错误。这使得 C++的违例控制机制显得用处不大。

我们在这个地方可采取欺骗手段：要求“掷”出一个并没有发生的违例。编译器能理解我们的要求，并强迫使用这个方法的用户当作真的产生了那个违例处理。在实际应用中，可将其作为那个违例的一个“占位符”使用。这样一来，以后可以方便地产生实际的违例，毋需修改现有的代码。