开发/用于Internet Explorer [英] developing with / for internet explorer
问题描述
你好，
我创建了一些相当复杂的Intranet应用程序，使用了大量的
JavaScript，DOM-Maninpulation和XMLHTTPRequest通信。
我是在FireFox上开发的，有着优秀的萤火虫......每一次不法行为
都被给予了精美，精美的追溯;完全指向错误的
代码。
我的代码在FireFox和Opera上正常运行。
现在有些人要求让这个应用程序与Internet一起运行
Explorer;并且它在JavaScript的语法检查时失败。那肯定应该是可以修复的，但更大的问题是：
Internet Explorer只给我一个错误框，其中有些虚假
行和字符，他检测到错误。
启用调试并从Microsoft安装scriptdebugger
（奇怪的是，只运行管理员权限），给我一个
调试窗口。并且：在每个错误中，MochiKit主JS文件在开始时打开了
。
我很确定错误是在我的JavaScript中，而不是在
MochiKit。
所以我大声呼救：你如何通过互联网解决JS错误
资源管理器？是否有任何秘密武器可以获得至少可用的线路
数字;甚至是错误的追溯？
我不需要一个完整的调试器，允许我单步和
全部。只是此行导致了您的错误可用的这个会是
够了。
有什么建议吗？
Harald
GHUM写道：
< snip>
Internet Explorer只给我一个错误框，其中包含一些
而不是伪造的行和字符，他在那里检测到了
错误。
表面上看，这是IE错误消息给出的印象。
但是，虽然错误消息通常显示不正确的行
数字，例如，它们一直是不正确的（因为你希望从软件中获得
期望（一致性不一定是不正确的），并且
消息本身一直是相关的提出
错误的问题，即使它们并不总是具体关于错误
是什么。例如，xxx.yyy是null或不是对象总是意味着
xxx没有解析为对象的引用，因此无法在该对象上查找''yyy''属性
，对象预期是一个尝试
来调用一个函数，其中函数的标识符没有解析为对象中的
，并且''xxx''未定义试图引用标识符所具有的
标识符没有被宣布。消息
本身可能不是特别明显，但他们与原因的关系是一致的，可以通过经验来学习。
< snip>
我更确定错误是在我的JavaScript中，
不在MochiKit中。
虽然我不相信微软的脚本调试器，但我已经看到
人们确信浪费了相当多的时间
问题并不在于自动化工具说他们是什么的地方，以及从长远来看它们实际上是在哪里。
所以我大声呼救：你如何使用Internet Explorer解决JS错误
？是否有任何秘密武器可以获得至少可用的行数;甚至是错误的追溯？
< snip>
除了观察一些模式，例如事件处理中的错误
函数内部由内部事件属性值生成
总是声称在第一行，了解哪些错误是由
引起的，哪些问题会告诉你什么类型的东西你正在寻找，并且
实际上定位违规行通常可以通过对问题应用
逻辑来实现。
因为错误输出是一致的，修改输入并查看输出更改的方式可用于扣除错误'
位置。例如，假设您有一个嵌入了
javascript的HTML页面和两个导入的javascript文件，并在
第45行报告错误。如果你转到javascript文件并且将一个空白行添加到
顶部的一行和两行空行到另一行的顶部并重新加载并且
重现错误，如果行号现在是47问题出现在
第二个javascript文件中，46并且它在第一个，仍然是45个意味着
问题出现在HTML页面代码中，关于或关于第45行。
同样，在javascript文件中找到确切的代码行;如果
错误报告显示第45行，则实际错误将在第45行的附近
附近，但不一定在该行。你去，比如说，
第42行并在其后添加一个空行，跳过下一行代码和
添加另一个空白行，跳过下一行代码并添加另一个
空白，依此类推，插入6个空白行。如果重新产生错误
现在声称它在第48行，你确切地知道它在
上的哪一行，因为它是插入第三个空行之后的行。
Richard。
JRS：文章< e9 ************** *****@news.demon.co.uk> ;,日期，星期六，15
2006年7月13:45:06远程，见于新闻：comp.lang.javascript，Richard
Cornford< Ri ***** @ litotes.demon.co.ukposted：
>
同样，找到确切的javascript文件中的代码行;如果
错误报告显示第45行，则实际错误将位于第45行的附近，但不一定在该行。你去，比如说，第42行，然后在它后面添加一个空白行，跳过下一行代码并添加另一行空白行，跳过下一行代码并添加另一行
空白等等，插入说6个空白行。如果重新产生错误
现在声称它在第48行，你确切知道它在哪一行
，因为它是插入第三个空白行之后的行。
这不一定是真正错误的位置;这是位置
，其中Javascript意识到发生了错误。
考虑到不取消注释声明的错误：
// var x
/ * * /
x
错误在第一行，但是在第三个报告中。
我希望在检测到不可能性存在之前，可以找到其他实例，其中实际错误很好
。
a = b = 1
c = a / * b //但是信息很清楚
-
？约翰斯托克顿，英国萨里。 ?@merlyn.demon.co.uk Turnpike v4.00 IE 4？
< URL：http：//www.jibbering.com/faq/>？ JL / RC：新闻常见问题：comp.lang.javascript
< URL：http：//www.merlyn.demon.co.uk/js-index.htmjscr数学，日期，来源。
< URL：http：//www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/& c，常见问题项目，链接。
John Stockton博士写道：
>
这不一定是真实的位置错误;它是
位置，Javascript意识到发生了错误。
如果只有完整的静态分析可用！
如果不这样做，jslint是你的武器库中的好工具：
http://www.jslint.com/lint。 HTML
Joshua
Hello,
I created some rather complex Intranet Application, using lots of
JavaScript, DOM-Maninpulation and XMLHTTPRequest communication.
I developed on FireFox, with the excellent firebug ... every misstake
was given back with a fine, fine traceback; exactly pointing to the
code at error.
My code runs fine on FireFox and Opera.
Now some people demand to have that application running with Internet
Explorer; and it fails at the syntax check of the JavaScript. That
surely should be fixable, but the bigger problem is:
Internet Explorer just gives me an error box with some rather bogus
line and character where he detected the error.
Enabling debugging and installing the scriptdebugger from Microsoft
(which, oddly enough, only runs with admin privileges), gives me a
debugging window. And: at each error the MochiKit main JS File is
opened at the beginning.
I am rather sure that the errors are within my JavaScript, not in
MochiKit.
So I am crying out for help: How do you resolve JS errors with Internet
Explorer? Is there any secret weapon to get at least usable line
numbers; or even a traceback of an error?
I do NOT need a full blown debugger, allowing me to single step and
all. Just "this line caused your error" with a usable "this" would be
enough.
Any suggestions?
Harald
GHUM wrote:
<snip>Internet Explorer just gives me an error box with some
rather bogus line and character where he detected the
error.Superficially that is the impression given by the IE error messages.
However, while the error messages do usually show incorrect line
numbers, for example, they are consistently incorrect (as you would
expect from software (consistency not necessarily incorrectness), and
the messages themselves consistently relate to the issue raising the
error, even if they are not always that specific about what the error
is. For example, "xxx.yyy is null or not an object" always means that
xxx did not resolve as a reference to an object so a ''yyy'' property
could not be looked up on that object, "object expected" is an attempt
to call a function where the Identifier for the function did not resolve
into an object, and "''xxx'' is undefined" is an attempt to reference an
Identifier where the Identifier has not been declared. The messages
themselves may not be particularly obvious but their relationships with
their causes is consistent and can be learnt with experience.
<snip>I am rather sure that the errors are within my JavaScript,
not in MochiKit.Although I would not trust Microsoft''s script debugger, I have seen
considerable amounts of time being wasted by people being certain that
the problem did not lie in the locations where automated tools said they
were, and where they actually turned out to be in the long run.
So I am crying out for help: How do you resolve JS errors
with Internet Explorer? Is there any secret weapon to get
at least usable line numbers; or even a traceback of an error?<snip>
Apart form observing some patterns, such as that errors in event handing
functions internally generated from Intrinsic event attribute values
invariably claim to be on line one, learning which errors are caused by
which issues will tell you what type of thing you are looking for, and
actually locating the offending line can usually be achieved by applying
logic to the question.
Because the error output is consistent, modifying the input and seeing
how the output changes can be used to make deductions about the error''s
location. For example, suppose you have an HTML page with embedded
javascript and two imported javascript files, and an error reported on
line 45. If you go to the javascript files and add one blank line to the
top of one and two blank lines to the top of the other and re-load and
reproduce the error, if the line number is now 47 the issue is in the
second javascript files, 46 and it is in the first, and still 45 means
the issue is in the HTML page code, on or about line 45.
Similarly, finding the exact line of code in a javascript file; If the
error report says line 45 the actual error will be in the immediate
vicinity of line 45, but not necessarily on that line. You go to, say,
line 42 and add a blank line after it, skip the next line of code and
add another blank line, skip the next line of code and add another
blank, and so on, inserting say 6 blank lines. If re-producing the error
now claims that it is on line 48 you know exactly which line it is on
because it is the line following the third blank line inserted.
Richard.
JRS: In article <e9*******************@news.demon.co.uk>, dated Sat, 15
Jul 2006 13:45:06 remote, seen in news:comp.lang.javascript, Richard
Cornford <Ri*****@litotes.demon.co.ukposted :>
Similarly, finding the exact line of code in a javascript file; If the
error report says line 45 the actual error will be in the immediate
vicinity of line 45, but not necessarily on that line. You go to, say,
line 42 and add a blank line after it, skip the next line of code and
add another blank line, skip the next line of code and add another
blank, and so on, inserting say 6 blank lines. If re-producing the error
now claims that it is on line 48 you know exactly which line it is on
because it is the line following the third blank line inserted.
That''s not necessarily the location of the real error; it''s the location
where Javascript realises that an error has occurred.
Consider the error of not uncommenting a declaration :
// var x
/* */
x
The error is in the first line, but reported on the third.
I expect other examples can be found in which the actual error is well
before where the presence of an impossibility is detected.
a = b = 1
c = a /* b // but message is clear
--
? John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ?
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Dr John Stockton wrote:>
That''s not necessarily the location of the real error; it''s the
location where Javascript realises that an error has occurred.If only full static analysis was available!
Failing that, jslint is a good tool to have in your arsenal:
http://www.jslint.com/lint.html
Joshua
这篇关于开发/用于Internet Explorer的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
