3

私は比較的巨大なECMAScriptコードベース（> 60,000 LOC）に取り組んでおり、恐ろしい友人であるInternet Explorer（特に6と7）のエラーの検出に少し苦労する傾向があります。

現時点では、RIAがGoogle Chrome、Firefox 3.6、Opera、Internet Explorer 8で正常にレンダリングされるという問題に3日間悩まされていますが、Internet Explorer 8をIE7モード（または実際のIE）で実行すると失敗します-7）。

私の質問は本当にです：IE7でエラーを生成するコードを特定するにはどうすればよいですか？

通常、私はJSLintに依存しており、通常の容疑者を捕まえる傾向があります（末尾のコンマ、嫌いです）が、この特定のケースでは、ソースと最小化の両方のすべてのコードでリンターを再実行しましたが、そうではありません私のいつもの容疑者を譲ります。だから私はIEが気に入らないものを誤って導入したと思います（誰が知っているので、どこかでdojo.mapの代わりにArray.mapを使用しましたか？）そしてそれは私の顔に爆発し、そうでない素晴らしいエラーメッセージを生成します私を助けてください（「[オブジェクトオブジェクト]」と「null」は本来あるべきではないので、上流でエラーが発生し、サイレントに失敗してこのオブジェクトを作成できなかったと思います）。

Google Closure Linterを試してみましたが、特別なことは何も得られず、GoogleClosureCompilerも私の救世主になるとは思いません。適切なエラーを取得できるように、IEをエミュレートしているかのようにコードを解析/実行できるツール（コマンドライン、Webサービスなど）はありますか？

ヒントをいただければ幸いです。

編集：これまでの私の問題を解決するためにあなたの助けをありがとう、しかし私が本当に求めているのは、特定のブラウザに対して機能セットと構文を検証することを意味する、この種のチェックを行うツールがあるかどうかです。これは、私の意見ではJSの世界にひどく欠けている種類のものです（FFやChromeの場合はそれほど多くはありませんが、明らかにデバッガーの方が少し便利です）。

EDIT2：2つのブランチ間のすべてのコード変更を調べ、問題は実際にはすでに存在しているが、以前は検出されなかったことに気づき、さらに古い変更を繰り返して絞り込んだことで、最終的に今日（3日後）に問題の根本を見つけました。混乱し、最終的には障害点に達するまでどこにでもコンソールログを追加することになります（すべての行にログを追加する正規表現のサポートについてemacsに感謝します...重いですが機能します...）。面白い事実：IEは、元々ソースの問題をキャッチしてから再スローするtrycatchブロックに表示されるはずのエラーメッセージを飲み込んだ。それでも理由はわかりませんが、そうでなければ、壊れた場合に備えてその目的のために意図されていたので、見つけるのははるかに簡単でした。変。深いレベルの再スローは好きではないかもしれません。

今のところ、実際の質問に対する答えはありませんので、質問は開いたままにしておきます。

4

2 に答える 2

2

@galambalazsが示唆しているように、IE8デバッガーを試すことができます。IE6時代の古いデバッガーは一般的に役に立ちませんでした。

私がいつも使用している低レベルの手法は、Javascriptソースの大部分の周りに独自のtry / catchブロックを追加して、エラーのソースを絞り込むことです。try / catchブロックを繰り返し調整することで、ソース全体で「バイナリ検索」を実行して、例外の原因となっているコードを見つけることができます。Firefoxには無害であるが、IEのインタープリターがエラーと見なすコードがあることがおそらくわかるでしょう。（公平を期すために、通常、IEの厳格さは正当化され、Firefoxの緩い動作は本当に望ましくありません。）

つまり、疑わしいJavascriptソースから開始するか、含まれているすべての.jsファイルに対してこれを実行する可能性があります。

// top of Javascript source file foo.js
try {
  // ... all the code ...
} catch (x) { alert("Error in foo.js: " + x); }

ここで、ページを読み込んでそのアラートを受け取ると、エラーがfoo.jsのどこかにあることがわかります。したがって、それを半分に分割します。

// top of foo.js
try {
  // ... half the code, roughly ...
}
catch (x) { alert("Error in first half of foo.js: " + x); }
try {
  // ... the rest of the code ...
} catch (x) { alert("Error in second half of foo.js: " + x); }

そのプロセスを繰り返すと、最終的に問題が見つかります。

于 2010-11-24T13:54:29.573 に答える
0

MicrosoftScriptDebuggerまたはInternetExplorerDeveloperToolsを試すことができます。

IE 8で以前のバージョンと異なる可能性があるものの完全なリストについては、以下を参照してください。

考えられる癖については、 Webバグトラックも参照してください。

最後に、console.logすべての行で実行すると、特定のバグを難しい方法で見つけるのに役立つ場合がありますが、コードの量を考慮すると、モジュールの単体テストを実際に作成する必要があります。これが、アプリケーションが実際にさまざまな入力と条件で実行されることを確認できる唯一の方法です。

于 2010-11-24T13:50:42.507 に答える