程序开发中最经常做的事情莫过于debug，在webMethods中也是如此。掌握有效的debug方法可以提高程序开发的效率，而了解更多的debug方式则让bug无处遁形。

在这里我列举几个常用的debug方式。

一、最常用的单步调试和Trace。

在developer中，单步调试的快捷键是F6，Trace是F5。本人在发现程序存在错误的时候最先使用的找错方式便是用Trace运行程序，当程序跑到异常的地方，trace会中断运行，并且可以留下运行过的标志。我们可以很清楚地看到出错的地方。接着我们便可以拿出单步调试了，trace到附近，再一步一步跑进去，看看pipeline里面传的是什么值，是否符合逻辑。

二、规范：try-catch

当发现程序存在异常时，我们可以尝试使用try-catch捕获这个异常。通过分析getlasterror中的异常信息，很有可能就能找到异常出现的位置和原因。当然也有分析不出来原因的情况，这就需要有丰厚的经验和逻辑推理的能力了。try-catch在编写程序的时候也是十分重要的规范，因为一旦异常发生，我们不希望程序就此中断，而是让程序接着跑完，但是异常信息需要保留下来给我们查看。这个方法跟trace相比的优点在于debug的时间短，因为我们只需要直接运行程序就好了。当我们要debug一段十分长的代码，又或者是要进行一个大循环的话，try-catch是一个好工具。

三、pipeline debug

这个方法在使用invoke调用程式的时候十分有效。首先，我们需要设置service的PipeLine Debug值为save，再运行程序，当跑完程序之后回去将pipeline debug设置为restore（override），再单独运行需要调试的程序，这个时候pipeline里面会保存上一次我们运行程序时用过的参数。除了这样设置，我们也可以用wmPublic/pub/flow中的savePipeline和restorePipeline方法。这个方法能很有效地帮助我们调试不可以使用单步调试进入的程式。

四、debugLog

wmPublic/pub/flow中除了刚才提到的savePipeline和restorePipeline方法，还有debugLog方法。这个方法在调用的时候会往服务器的log-server中发送message，通过这个message我们可以知道程式有没有跑到这个对应位置。这个方法在有些时候还是十分实用的，例如：当我们在远程客户端调用IS上的service时，我们可能并不知道程式有没有被调用，而如果我们在程式中加入debugLog方法，我们就可以去服务器的log中找我们预留的message，找到了便说明调用成功了。

五、小技巧

在debug的过程中我们可以使用的方法远不止上述的这些，例如我们想检测一下某个参数超过了一定的位数会不会造成影响的时候，我们可以直接hardcode这个参数进行调试；又例如我们在找不到错误发生的位置的时候，我们可以找一下这个程式的引用，看看在某些引用中是否发生了错误；还有就是一些公共的方法也有可能带来bug，这时我们可以找到这个方法直接运行一下；当然，还有一个好技巧——请教经验丰富的同事。

webMethods中的debug