用科学化除错方法替你的 zk 程序除错之二

b. 分析找到的资料并给出一个对根因的假设

在取得资料之後，就要针对这些资料提出一个假设。如果对 ZK 的内部运作越了解，就越能够提出越正确的假设。

让我们概略地看一次先前提过的 AU reqeust 处理流程：

以上步骤可以简化为：

1. 浏览器发出 ZK AJAX 请求 （或称 asynchronous update，简称 AU)
2. 服务器事件倾听器执行
3. 浏览器收到 AJAX 回应 （AU response）

每次当你跟元件互动但结果不如预期的时候，就可以依次检查以上三个步骤有无正确执行:

1. 是否发出预期的 ZK AU
2. 倾听器是否执行
3. AU 回应内容是否如预期

c. 证明或反证该假设

当你提出一个对问题根因的假设之後，如果能够证明假设成立，恭喜你，已经发现问题根源，可以开始思考怎麽解决。如果假设无法证明或可反证它，那就代表先前的假设错误，你要回到前一步，重新提出另一个假设。如此反覆到找到根因为止。以下提供几个方法帮助你检查 ZK 运作是否正常来验证你的假设：

是否发出预期的 ZK AU

你可以透过 developer tool 来观察，以 Chrome 为例，按 F12 打开，选 Network 页，当你操作某个 ZK 元件而发出 event 时，会有一个路径为 zkau 的请求发出如下：

确认 AU 的确有发出之後，就该检查是否是你预期的事件发出，因着使用者与元件互动的行为，就应产生对应的事件，例如按了按钮就会发出 onClick、打开 popup 就发出 onOepn。如果没发出就该检查是否注册 listener 有问题。有关AU request 内容请参考前几天基本知识的文章。

倾听器（event listener）是否执行

如果使用者触发的事件，在服务器端有注册对应的倾听器 method，则 ZK 会呼叫该 method。要确认该 method 是否有被呼叫，可以印 log或透过 IDE 在 Java class 中设定中断点。

AU 回应内容是否如预期

当 event listener 执行完後，其中所中呼叫的元件 API(主要是 setter)会产生相对的 AU 回应，这些回应内容包含对 client widget 的命令。因此不管是设定属性、新增/删除子元件，回应内容都会包含这些命令。你可以透过 developer tool 检查 AU 回应的内容是否符合你事件倾听器的实作。AU 回应的内容请参考前几天基本知识的文章。