Lync.in

本文所描述的场景并不是常见，如果你的脚本并没有很多层嵌套，如果你的脚本不是以动态载入的形式来执行，那么这个很复杂很纠结很麻烦的事情你应该也不会遇到。

很不幸的，在我的工作中，不但会有一个很深层的递归，会动态的载入JS，而且还有eval这样的global code。哦，对了，还有多frame的操作。

好的，让我们开始这个很棘手的事情。

也许你很经常会看到这样的场景。

是的，这是一个脚本异常，在IE中非常常见的一个脚本异常。那么如果这里的Line是一个9位数呢？比如152345279或者512369027，是不是有点抓狂了呢？

S同学也不是什么超人，做不了这等亿万行代码的工作，入行至今写的代码也不及这个零头。那么为什么会那么多行呢？因为这个已经是内存中的行数了。再之后进去调试，调试器会告诉你，source code is not accessible，的确，这些代码都不是明文写在网页中，并没有document.write()之类或者直接写在<script>中。正如前文所述，这些脚本是用动态加载技术读入的（相关内容可以看这篇博客《动态载入脚本和CSS》），所以其内容是完全载入在内存之中，而在文本的表现中是缺失的。也正是因为如此，其调试才显然相对困难。

当然也有办法。

在调试中，你也许会碰到许许多多层的anonymous function，然后你会对这是哪个函数而迷惑不已。当然，通过local variables，通过去看this的具体内容，你可以大致猜测到具体是哪个函数，但如果用以下这句话，也许会更容易一些。
arguments.callee().toString()

其实这句的目的就是打印出当前调用的函数的内容。当你通过函数的内容来找到对应的代码，事情就容易得多了。在那以后，根据错误消息的提示及对变量的观察，就可以找到问题的根源了。

还有些场合，比如weblogic这样的application server之上，会对脚本文件的长度进行cache，如果你的文件被改动过，那很有可能真正你的浏览器下载的脚本文件并不完全。并极有可能带来一些JS解析执行时的错误。所以，如果碰到错的时候，不妨先看看你到手的JS到底长得啥样。

通过XUL来制作的Firefox在调试的时候，特别是一些比较精确的调试的时候，效果反而不如IE系的几个东西来得舒服。而Opera和Webkit东西在调试的时候，就显得更不方便了。虽然在一般调试的时候，Firebug，DragonFly和Web Inspector依然是非常强大非常好用的工具。

如果有错，还望各位不吝指正。