Должен ли я использовать try-catch при вызове плагина jquery

Question

Итак, у меня есть плагины jquery (или любые другие плагины / функции / библиотеки, для чего это важно).

Мне было интересно, должен ли я вызывать плагин внутри try-catch, чтобы избежать любых неопределенных ошибок типов, которые могут блокировать выполнение остальной части скрипта.

Вот как / где я сейчас называю плагины.

(function($){
    $(document).ready(function(){

        // jquery plugin
        try {
            $("#app").plugin();
        } catch (e) {
            console.log(e);
        }

        // some other function applied to entire document
        try {
            libraryFunction();
        } catch (e) {
            console.log(e);
        }
    });
})(jQuery);

Я знаю, что это не проверка кода, но если у вас есть предложения по улучшению этого кода, пожалуйста, дайте мне знать.

Answer 1

Я имел дело со сценариями, когда ошибка плагина фактически испортила остальную часть скрипта, и использование try-catch для вызова плагина решило проблему.

Использование try-catch много может замедлить ваш скрипт,но если вы не имеете дело с длинными циклами, изменение производительности будет незаметным.

Answer 2

Всегда полезно обрабатывать неизвестное поведение с помощью блока try-catch.Но еще важнее знать, как обрабатывать исключение после его обнаружения.В приведенном выше коде исключение только регистрируется (что хорошо) и ничего больше.В этом случае ваше выполнение все еще может быть заблокировано.

Кроме того, было бы хорошо также выбросить исключение обратно вызывающей стороне и заставить его обрабатывать поведение.Например, в приведенном выше коде, если jquery выдал исключение, вы можете сообщить вызывающей стороне об этом исключении, и вызывающий может решить снова вызвать функцию или сделать что-то еще.

Короче говоря, после перехвата,обработка решает, как ваше исполнение будет восстановлено.Одно только ведение журнала не поможет.

Редактировать:

Пример, показывающий, почему следует отбрасывать исключение:

Допустим, у меня есть AppThread, который запрашивает рабочий поток дляхранить некоторые данные в базе данных SQL.Такой поток кода в идеале не требует, чтобы рабочий поток возвращал что-либо вызывающей стороне, поскольку рабочий поток просто выполняет некоторые операторы Insert.Теперь во время вставки рабочий поток поймал исключение SQLException и просто зарегистрировался и вернулся.Теперь поток приложения никогда не уведомлялся об этом исключении, и он просто предполагает, что данные были вставлены в соответствии с запросом.Через некоторое время AppThread теперь хочет прочитать те же данные из базы данных и просит WorkerThread извлечь их с использованием некоторого идентификатора.На этот раз код не сгенерирует никаких исключений, и набор результатов будет просто нулевым.Теперь запомните, AppThread был уверен, что данные будут присутствовать, и не будет знать, что делать, если набор результатов равен нулю.Таким образом, с одной стороны, выполнение кода блокируется после некоторого исключения.

Теперь, если бы Рабочий поток уведомлял об исключении в Потоке приложения ранее, AppThread был бы осведомлен и попытался бы повторно выполнить операцию вставки или отобразил бы диалоговое окно для пользователя, сообщающее ему / ему, что данныевозможно, потребуется проверить, прежде чем пытаться вставить снова.Также, как исключение было передано обратно, его сообщение дало бы больше подсказок о том, что пошло не так непосредственно пользователю.Ему не придется возвращаться к журналам, чтобы проверить, что пошло не так.