跨浏览器JavaScript调试（Moz / IE） [英] Cross Browser JavaScript Debugging (Moz/IE)
问题描述
致所有Mozilla JS Guru'（欢迎IE欢迎你），
我在过去三年里一直在开发复杂的DHTML
应用程序在IE 5.5sp2 +中工作，但我使用Mozilla 1.3 + **来完成我的所有开发。我已经构建了一些跨浏览器调试器，所以我的
用户可以向我发送详细的调试转储。我已经取得了一些成功，但是已经有了基本的底层JavaScript模型的障碍。
在IE中获得完整堆栈的唯一方法就是使用
window.onerror处理程序。此时通过浏览
arguments.callee.caller ...您可以将调用堆栈导航到错误的起始点。
。这有效，但它违背了
第一个基本的调试规则，即使用try {...} catch（尽可能接近
来源）处理错误。 e）{...}块。
不幸的是在Mozilla中，你不能通过使用来自window.onerror处理程序的
arguments.callee.caller来浏览堆栈：|
在Mozilla中，它们有error.stack，其中包含完整的堆栈和
它运行良好但只有在使用try / catch块时才可用。
但是，在IE中没有错误的堆栈属性，因此如果你使用try / catch来处理错误，你只会从当前的
中知道堆栈位置（处理的位置）到第一级。当前函数/方法丢失后所有调用
：[...示例 - 堆栈a（），
b（），c（），d（），e （），f（）在e（）处有错误，而try / catch在c（），在
IE中你只能获得a（） - b（） - c（）而你会不知道错误
是发生在c（），d（），e（）还是f（）。
这是一些可能的IE / Moz调试解决方案：
1）我当前的生产版本 - 使用try / catch块但是将
放在尽可能多的容易出错的地方并且接近错误源
分。当发生错误时，在全局数据结构中存储错误状态。
抛出错误并最终处理window.onerror中的错误。
在window.onerror中，读取全局调试存在并使用数据和
可能遍历调用堆栈到始发呼叫。 （在IE中，你仍然会从处理它的位置松散堆栈：[。但是在Mozilla中
我得到了很好的调试：]）
2）可能性1 - 只有尝试/捕获的结构代码
在Mozilla中运行。这需要简单的服务器端代码，如果是Mozilla，请使用try / catch块来支持
，并将其评论为
IE。
3）可能性2 - 在window.onerror中处理错误时，找到一种在Mozilla中获取错误对象的方法
。还没有找到任何方法来获取
这个我很想下载Mozilla源代码并自己编写
补丁。
4）可能性3 - 在使用try / catch时，在IE中找到一种从源获取堆栈的方法
错误。 IE目前没有堆栈
属性的错误（巨大的设计缺陷）。我甚至不会梦想
暗示这是微软的一个错误，因为我在道德上反对支付报告错误的
。此外，我绝不想在任何情况下看到
他们的源代码：P
任何想法都将不胜感激。
TQ
**（参见bug http://bugzilla.mozilla.org/show_bug.cgi?id=158592) 。这个
错误导致在Mozilla中遍历调用堆栈时出现问题。我报告了
这个并给Moz团队提供了一个相当不错的案例，并且最终修复了（&b）
（尝试与微软合作）。现在Moz 1.3+（Netscape
7+？）已经包含了这个补丁。
To all Mozilla JS Guru''s (IE dudes welcome),
I have spent the last three years developing complex DHTML
applications that must work in IE 5.5sp2+ but I use Mozilla 1.3+** to
do all my development. I have build some cross browser debuggers so my
users can send me verbose debug dumps. I have some success but have
come to a roadblock with the basic underlying JavaScript models.
The only way to get a complete stack in IE is to use the
window.onerror handler. At this point by surfing the
arguments.callee.caller... you can navigate the call stack to the
originating point of the error. This works but it goes against the
first basic rule of debugging which is to handle the error as close to
the source as possible using try{...}catch(e){...} blocks.
Unfortunately in Mozilla, you cannot surf the stack by using
arguments.callee.caller from window.onerror handler :|
In Mozilla, they have error.stack which contains the full stack and
it works great but is only available if you use try/catch blocks.
However, in IE there is no stack property of error therefore if you
handle the error with a try/catch you will only know from the current
stack position (where it is handled) to the first level. All calls
after the current function/method are lost :[ ... Example - stack a(),
b(), c(), d(), e(), f() has error at e() and try/catch is at c(), in
IE you can only get a()-b()-c() and you will not know if the error
happened at c(), d(), e(), or f().
Here is some possible IE / Moz debugging solutions:
1) My current Production version- use try/catch blocks but put
them in as many error prone places and as close to error source
points. When error occurs store error state in global data structure.
Throw the error up and ultimately handle the error in window.onerror.
At window.onerror, read if global debug exists and use data and
possibly traverse call stack to originating call. ( In IE, you still
loose the stack from the point where it is handled :[. But in Mozilla
I get great debugging :] )
2) Possibility 1 - Structure code such that try/catches only
operate in Mozilla. This would need simple server side code to serve
up JavaScript with try/catch blocks if Mozilla and comment them out if
IE.
3) Possibility 2 - Find a way to get the error object in Mozilla
when handling error in window.onerror. Have not found any way to get
this yet and I am tempted to download the Mozilla source and write the
patch myself.
4) Possibility 3 - Find a way to get the stack from the source
error in IE when using try/catch. IE currently does not have a stack
property of error (Huge design flaw). I would never even dream of
suggesting this as a bug to Microsoft as I am morally against having
to pay to report bugs. Also I would never in any event want to see
their source code :P
Any ideas would be greatly appreciated.
TQ
** (See bug http://bugzilla.mozilla.org/show_bug.cgi?id=158592). This
bug caused problems when traversing call stack in Mozilla. I reported
this and made a reasonably good case to the Moz team and it was and
eventually fixed (Try that with Microsoft). Now Moz 1.3+ (Netscape
7+?) has had this patch included.
推荐答案
2004年4月18日16 ：58：56 -0700， de********@yahoo.ca （Java脚本
Dude）写道：
On 18 Apr 2004 16:58:56 -0700, de********@yahoo.ca (Java script
Dude) wrote:
我已经构建了一些跨浏览器调试器，所以我的
用户可以发送详细的调试转储。我取得了一些成功，但是已经找到了基本的底层JavaScript模型的障碍。
我从来没有发现在JS中需要这些类型的调用堆栈，并且
肯定从来没有发现需要在<发货内容，这让我感到震惊，因为我建议你不要把想法错误地放在哪里，并且不是
/>
足够防守。
1）我当前的生产版本 - 使用try / catch块但是将它们放在尽可能多的容易出错的地方并且接近错误源
点。
当然你应该总是捕捉已知的错误，并且最好
应该阻止所有预期的，你真的得到
这个调试代码的值是多少？
2）可能性1 - 结构代码使得try / catches只能在Mozilla中运行。这需要简单的服务器端代码来提供
oops，这条线已经取消了自己的线索，
你无法识别IE / mozilla服务器，通过这样做你只是
介绍自己的其他问题。
我甚至都不会梦想将这作为微软的错误提示给我我在道德上反对支付报告错误的费用。
您无需付费向MS报告错误。
任何想法都将不胜感激。
I have build some cross browser debuggers so my
users can send me verbose debug dumps. I have some success but have
come to a roadblock with the basic underlying JavaScript models.
I''ve never found the need for these sort of call stacks in JS, and
have certainly never found the need for verbose debugging code in
shipped content, it strikes me as suggesting that you''re not putting
enough thought into where you''re likely to error, and aren''t being
defensive enough.
1) My current Production version- use try/catch blocks but put
them in as many error prone places and as close to error source
points.
Surely you should always be catching known errors, and preferably
should be preventing all that are expected, are you really getting
value out of this debug code?
2) Possibility 1 - Structure code such that try/catches only
operate in Mozilla. This would need simple server side code to serve
oops, this line has already disqualified yourself from having a clue,
you cannot identify IE/mozilla on the server, by doing so you''re just
introducing yourself other problems.
I would never even dream of
suggesting this as a bug to Microsoft as I am morally against having
to pay to report bugs.
You don''t need to pay to report bugs to MS.
Any ideas would be greatly appreciated.
编写防御性代码，在已知区域使用更多try / catches，使用
onerror方法作为最终希望捕获。
吉姆。
-
comp.lang.javascript常见问题 - http://jibbering.com/faq/
Write defensive code, use more try/catches in known areas, use the
onerror approach as a final hope catch.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
> >我已经构建了一些跨浏览器调试器，所以我的
> >I have build some cross browser debuggers so my
用户可以向我发送详细的调试转储。我已经取得了一些成功但是已经找到了基本的底层JavaScript模型的障碍。
我从来没有发现JS需要这些类型的调用栈，而且肯定没有发现需要在发布的内容中使用详细的调试代码，这让我觉得你没有充分考虑到你可能会出错的地方，并且不是<足够防守。
users can send me verbose debug dumps. I have some success but have
come to a roadblock with the basic underlying JavaScript models.
I''ve never found the need for these sort of call stacks in JS, and
have certainly never found the need for verbose debugging code in
shipped content, it strikes me as suggesting that you''re not putting
enough thought into where you''re likely to error, and aren''t being
defensive enough.
我说的是DHTML应用程序而不是带有JavaScript的页面（DHTML
Page / Document）。应用程序意味着使用库的代码将需要在调用堆栈中低于3个级别。没有阅读堆栈
任何超过两个级别的深度都很难调试（有时候不可能是b $ b）。我有一些JavaScript（多年来一直在制作
），在堆栈中超过7个级别。这段代码可能是完整的，但至少它是可调试的。
I am talking about DHTML Applications not pages with JavaScript (DHTML
Page/Document). Applications imply code that uses libraries and will
need to go below 3 levels in a call stack. Without reading a stack
anything more than two levels deep is very difficult (and sometimes
impossible) to debug. I have some JavaScript (That''s be on production
for years) that go more than 7 levels deep in the stack. This code may
be complete but at least it is debuggable.
1）我当前的生产版本 - 使用try / catch块但是将它们放在尽可能多的容易出错的地方并且接近错误源点。
1) My current Production version- use try/catch blocks but put
them in as many error prone places and as close to error source
points.
当然你应该总是知道错误，最好是
应该阻止所有预期的，你真的从这个调试代码中获得了价值吗？
Surely you should always be catching known errors, and preferably
should be preventing all that are expected, are you really getting
value out of this debug code?
我同意，更多的处理程序更适合在Moz中进行调试（在IE中），它只是处理错误的重要因素。堆栈到底有多远没什么问题。
I agree, more handlers is better for debugging (in IE) in Moz, it''s
only important to handle the error. How far up the stack does not
matter.
2）可能性1 - 结构代码如此尝试/捕获仅在Mozilla中运行。这需要简单的服务器端代码来提供
2) Possibility 1 - Structure code such that try/catches only
operate in Mozilla. This would need simple server side code to serve
oops，这条线已经取消了自己的线索，
你无法在服务器上识别IE / mozilla，通过这样做所以你只是介绍自己的其他问题。
oops, this line has already disqualified yourself from having a clue,
you cannot identify IE/mozilla on the server, by doing so you''re just
introducing yourself other problems.
Clue numero uno：尝试页面：
http://cyscape.com/products/bhawk/javabean.asp 。你会看到它
可以检测到Mozilla。 （JavaBean.asp？Sacralige是什么意思）
Clue numero uno: Try page:
http://cyscape.com/products/bhawk/javabean.asp. You will see that it
can detect Mozilla. (JavaBean.asp? What Sacralige)
我甚至都不会梦想将此视为微软的错误我在道德上不反对报告错误。
I would never even dream of
suggesting this as a bug to Microsoft as I am morally against having
to pay to report bugs.
你不需要付钱来向MS报告错误。
You don''t need to pay to report bugs to MS.
我之前尝试过，他们总是要求我
I have tried before and they always asked me for
报告因为道德原因而被拒绝的错误。 Bugzilla只是接受了错误并修复了它并且
甚至包括我在这个过程中：]我很高兴。如果我在
中发现了一个错误IE就可以解决它，在Moz中我报告它是因为它没有白费。
to report the bug I
refused on moral grounds. Bugzilla just takes the bug and fixes it and
even includes me in the process :] Me be happy. If I detect a bug in
IE just work around it, in Moz I report it because it is not in vain.
任何想法非常感谢。
编写防御性代码，在已知领域使用更多的尝试/捕获，使用
onerror方法作为最终希望捕获。
Write defensive code, use more try/catches in known areas, use the
onerror approach as a final hope catch.
我完全同意。直到IE给我们一个堆栈属性和Mozilla
给我们window.onerror的错误对象，这是最好的
技术。
Tim
I agree completely. Until IE gives us a stack property and Mozilla
gives us the error object at window.onerror, that is the best
technique.
Tim
这篇关于跨浏览器JavaScript调试（Moz / IE）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
