Найти IE-нарушающие ECMAScript / JavaScript ошибки - PullRequest
Новая
       17

Найти IE-нарушающие ECMAScript / JavaScript ошибки

3 голосов
/ 24 ноября 2010

Я работаю над сравнительно большой кодовой базой ECMAScript (> 60 000 LOC), и мы склонны немного бороться с обнаружением ошибок для нашего страшного друга Internet Explorer (особенно 6 и 7).

В данный момент яМы застряли с проблемой в течение 3 дней, когда моя RIA хорошо отрисовывается в Google Chrome, Firefox 3.6, Opera и Internet Explorer 8, но не работает при запуске Internet Explorer 8 в режиме IE7 (или с настоящим IE-7).

Мой вопрос на самом деле таков: как вы определяете код, который будет вызывать ошибку в IE7?

Обычно я полагаюсь на JSLint и склоняюсь к ловле обычных подозреваемых (конечные запятые, я ненавижувы), но в данном конкретном случае я только что повторно запустил линтер для всего своего кода, как исходного, так и свернутого, и это не дает моих обычных подозреваемых.Так что, я думаю, я по ошибке ввел что-то, что не нравится IE (кто знает, может, я сошел с ума и использовал где-нибудь Array.map вместо dojo.map?), И это взрывается у меня на лице, создавая хорошие сообщения об ошибках, которые немне вообще ничего не помогает («[объект объект]» и «ноль» там, где это не должно быть, поэтому я предполагаю, что произошла восходящая ошибка, которая молча завершилась неудачей и не позволила создать этот объект).

Я попытался взглянуть на Google Closure Linter, но он ничего особенного не дает, и я не думаю, что Google Closure Compiler будет моим спасителем.Есть ли какой-либо инструмент (командная строка, веб-служба или другой), который может анализировать / запускать код, как если бы он эмулировал IE, чтобы мы могли получить соответствующие ошибки?

Любые советы приветствуются.

РЕДАКТИРОВАТЬ: Спасибо за вашу помощь в попытке решить мою проблему до сих пор, но на самом деле я просто спрашиваю, есть ли инструменты, которые делают такого рода проверки, что означает проверку набора функций и синтаксиса для конкретного браузера.На мой взгляд, этого не хватает в мире JS (не так много для FF или Chrome, очевидно, поскольку их отладчики немного более полезны).

РЕДАКТИРОВАТЬ 2: В конце концов я нашел кореньМоя проблема сегодня (через 3 дня): я прошёл через все изменения моего кода между двумя ветвями и понял, что проблема на самом деле уже была, но никогда не обнаруживалась ранее, и прошёл через ещё более старые изменения, чтобы сузить беспорядок и, в конце концов, добавить журналы консоли.везде, пока я не достиг точки отказа (Боже, спасибо emacs за поддержку регулярных выражений для добавления журналов в каждую строку ... тяжело, но работает ...).Интересный факт: IE проглотил сообщение об ошибке, которое должно отображаться в блоке try catch, первоначально перехватив исходную проблему, а затем перезапустил ее.До сих пор не знаю почему, но если бы этого не было, найти его было бы намного проще, так как он был предназначен для этой цели на случай, если он сломается.Weird.Не похоже на глубокие уровни повторного броска.

Я оставлю вопрос открытым, так как пока нет ответа на настоящий вопрос.

Ответы [ 2 ]

2 голосов
/ 24 ноября 2010

Вы можете попробовать отладчик IE8, как подсказывает @galambalazs; старый отладчик из эры IE6 был вообще бесполезен.

Техника низкого уровня, которую я всегда использовал, заключается в добавлении моих собственных блоков try / catch вокруг больших частей моего источника Javascript, чтобы сузить источник ошибок. Итеративно настраивая ваши блоки 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); }

Повторите этот процесс, и вы в конечном итоге найдете проблему.

0 голосов
/ 24 ноября 2010

Вы можете попробовать Microsoft Script Debugger или Инструменты разработчика Internet Explorer .

Полный список того, что может отличаться в IE 8 от более старой версии, можно получить по адресу:

Также см. Web Bug Track для возможных причуд.

В качестве заключительного замечания, выполнение console.log в каждой строке может помочь вам найти конкретную ошибку сложным способом, но, учитывая объем кода, вы действительно должны написать модульный тест для модулей. Только так вы можете быть уверены, что ваше приложение будет работать с разными входами и условиями.

...