Вопросы Теги

Динамические Теги script для JSON запрашивают …, обнаруживающий, если существует XXX ошибок?

Строки кода полезны для знания, когда Вы задаетесь вопросом, становится ли файл кода слишком большим. Хм... Этот файл является теперь 5 000 строк кода. Возможно, я должен осуществить рефакторинг это.

5
задан rawrrrrrrrr 18 September 2009 в 20:10
поделиться

7 ответов

вместо этого используйте ajax. AFAIK нет способа определить, загружается ли тег скрипта или нет, а если нет, то почему он не загрузился. Используя ajax, вы можете загрузить json, и он скажет вам, почему он не загрузился.

С помощью библиотеки, такой как jQuery, это становится очень просто: 

$.ajax({
  type: "GET",
  url: "test.js",
  dataType: "script",
  error: function(xhr, error, exception){
    alert(xhr.status); //Will alert 404 if the script does not exist
  }
});
11
ответ дан 18 December 2019 в 07:55
поделиться

AFAIK, нет способа получить доступ к коду состояния некоторого внешнего ресурса, загруженного из документа (например, скрипта, стиля или изображения). Даже обнаружение ошибки (например, с помощью обработчика событий onerror ) не так широко поддерживается в браузерах.

Если все, что вы загружаете, подпадает под SOP , используйте XHR , который дает вам доступ к заголовкам ответов. В противном случае вы можете попробовать изучить недавно представленный X-домен XHR .

4
ответ дан 18 December 2019 в 07:55
поделиться

Если вы хотите обнаружить ошибки, прослушайте событие error и сравните свойство ошибки fileName с именем файла сценария. Если они совпадают, вы обрабатываете ошибку. Дело в том, что я думаю, что свойство fileName предназначено только для Firefox и Opera. Большинство браузеров, у которых есть трассировка стека для ошибок, также могут имитировать это поведение.

Вот пример, по просьбе Эрика Брешемье: 

var getErrorScriptNode = (function () {
    var getErrorSource = function (error) {
        var loc, replacer = function (stack, matchedLoc) {
            loc = matchedLoc;
        };

        if ("fileName" in error) {
            loc = error.fileName;
        } else if ("stacktrace" in error) { // Opera
            error.stacktrace.replace(/Line \d+ of .+ script (.*)/gm, replacer);
        } else if ("stack" in error) { // WebKit
            error.stack.replace(/at (.*)/gm, replacer);
            loc = loc.replace(/:\d+:\d+$/, "");
        }
        return loc;
    },
    anchor = document.createElement("a");

    return function (error) {
        anchor.href = getErrorSource(error);
        var src = anchor.href,
        scripts = document.getElementsByTagName("script");
        anchor.removeAttribute("href");
        for (var i = 0, l = scripts.length; i < l; i++) {
            anchor.href = scripts.item(i).src;
            if (anchor.href === src) {
                anchor.removeAttribute("href");
                return scripts.item(i);
            }
        }
    };
}());
0
ответ дан 18 December 2019 в 07:55
поделиться

Рекомендации IMHO по ведению журнала о том, что представляет собой хороший уровень операторов журнала редко встречается даже среди крупных фреймворков и продуктов, в первую очередь из-за более важных рекомендаций, связанных с

  • Подробность журнала - более подробные операторы должны отображаться как операторы отладки, а вызовы log.debug () должны быть заключены в вызов проверки включена ли отладка. Разработчикам часто необходимо правильно различать FATAL, ERROR, INFO, DEBUG и TRACE - не все исключения являются фатальными, и не все сообщения информативны.
  • Использование TRACE или аналогичного - это должно быть зарезервировано для потока выполнения. В идеале для указания потока управления никаких других операторов журнала не требуется.
  • DEBUG против INFO - операторы DEBUG часто предназначены для разработчиков и обслуживающего персонала; ИНФОРМАЦИЯ часто предназначена для пользователей и администраторов.
  • переопределить toString () - это полезно для регистрации состояния сложных объектов

Тем не менее, я следую нескольким общим правилам большого пальца на самом нижнем уровне:

  • Регистрировать данные как есть, без форматирования. Таким образом, в случае ошибки я знаю, какие данные вызвали проблему, вместо того, чтобы сомневаться в регистраторе, форматировщике и приложении одновременно.
  • Избегайте создания слишком большого количества объектов String, если вы не работаете с включенными DEBUG или TRACE. Короче говоря, избегайте объединения слишком большого количества строк. Даже если log4j в конечном итоге проверяет, включен ли DEBUG или нет, объекты String были созданы, и поэтому важна упаковка вызовов журнала.
1
ответ дан 18 December 2019 в 07:55
поделиться

Если вам нужно пересекать домены (и вам нужно, чтобы страница работала переносимо), вы должны использовать динамические теги скрипта.

Если у вас есть доступ к удаленному серверу, вы можете передать код ошибки с сервера, и страница сервера вернет 200.

Независимо от того, есть у вас доступ или нет, вы можете использовать setTimeout при создании тега сценария, передав функцию, которая вызовет ошибку, если срок ее действия истечет до вызова обработчика jsonp. Убедитесь, что обработчик jsonp прерывается, если обработчик ошибок был вызван.

Вам нужно будет отслеживать каждый запрос через глобальную коллекцию, но вы получите возможность отменять и подсчитывать запросы. Это похоже на то, как объекты XHR управляются такой библиотекой, как jQuery.

0
ответ дан 18 December 2019 в 07:55
поделиться

Я предполагаю, что вы хотите, чтобы это работало междоменно, поэтому вы не можете использовать XHR?

Попробуйте создать два тега сценария для каждого запроса, первый из них соответствует вашим стандартам Запрос JSONP, второй по сути является обработчиком ошибок.

Если выполняется первый тег сценария, очистите обработчик ошибок в обратном вызове. Но если первый получит 404, будет запущен обработчик ошибок во втором теге скрипта.

Возможно, вы также захотите установить тайм-аут, чтобы справиться с медленным ответом JSONP.

3
ответ дан 18 December 2019 в 07:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: