Javascript try..catch?

Question

[vaniaPooh]

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

Answer 1

[Константин Китманов]

Если в JSON.parse подать невалидный JSON, то он выкинет исключение. Вот тут-то и понадобится try..catch.

Answer 2

[Анатолий]

Не слушайте глупости выше, в javascript как и в любом другом языке нужно использовать try… catch. От ошибок ниток не застрахован, а этот блок как минимум покажет пользователю что произошла неизвестная/такая-то ошибка. лично я часто использую try как возврат из методов/функций, ибо не всегда удобно делать цепочку ретурнов, а иногда возникают ситуации что дальнейшее продолжение не нужно.
тот же аякс да, это отличный пример, пришли неверные данные
его же можно использовать для своих ошибок в библиотеках (крупные популярные библиотеки его активно используют)

Comments

[Сергей Протько]

Ну как бы никто и не отговаривает же. Просто в основной своей массе можно и без них обойтись. Это не значит что нужно без них.

[Анатолий]

«На клиентской части try/catch используются редко, потому ситуации с исключениями связаны с несуществующими методами/переменными/свойствами.»
Вот эта строка полная чушь =) То что Вы их не используете, или ваши коллеги, не значит что они не используются/используются редко. Они нужны однозначно. Это не просто проверка существования свойств и методов (которые на undefined прекрасно проверяются) это отличный помошник при проектировании сложных приложений.

Answer 3

[Сергей Протько]

На клиентской части try/catch используются редко, потому ситуации с исключениями связаны с несуществующими методами/переменными/свойствами. Но если речь идет скажем о работе с файлами или еще чего такое, они могут быть полезны. Так же полезно

Я увы мало работал с серверным JS, но когда разбирался с ним, а точнее выбирал между Erlang и Node.js мне на глаза попалась статья о том, что все в Node.js надо оборачивать в try/catch. Это связано с тем, что если что-то упадет, а ситуации бывают разные, то упадет и весь сервер. А вам это точно радости не прибавит.

Answer 4

[norlin]

Имхо, любой try-catch (по крайней мере, в javascript) — это борьба со следствием, а не с причинами. Есть ошибка — надо ее исправить, а не скрывать от пользователя.
Есть асинхронный\файловый метод — надо равно обрабатывать и успешное выполнение и если что-то пошло не так.
Например, в node.js можно повесить событие на «непойманный эксепшн» — полезно в боевых условиях, когда сервер не должен падать, несмотря на ошибку.
Но это — лишь как средство тестирования. Т.е., попалась ошибка — записали в лог — увидели — исправили.

Comments

[Борис Чумичев]

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

Answer 5

[mayhem]

если вы используете в своих библиотеках для возвращения ошибки throw Error(«message»), то и try… catch придется :)

Answer 6

[Борис Чумичев]

Как в случае браузерного, так и в случае серверного Javascript конструкция try/catch используется для отлова исключений в синхронных операциях (пример: десериализация JSON-данных или валидация данных которые ввёл пользователь). Если требуется обрабатывать ошибки в асинхронных операциях, то ошибка либо передается в callback-функцию (В Node.js общепринятым шаблоном вызова callback-функции является вызов вида callback(err, results), где лишь один из аргументов может принимать значения отличные от null.), либо в более сложных случаях генерируется событие 'error' объекта класса EventEmitter.

В Node.js try/catch используется очень редко (в основном только при парсинге JSON-данных), это объясняется тем что большинство операций в Node.js асинхронны, как правило ошибку передают в callback-функцию или генерируют событие "error" у объекта класса EventEmitter.

Вот пример иллюстрирующий, что try/catch не отловит исключение возникшее при выполнении асинхронной операции:

function myApiFunc(callback)
{
  /*
   * Пример некорректного перехвата исключений
   * в асинхронных операциях
   */
  try {
    doSomeAsynchronousOperation(function (err) {
      if (err)
        throw (err);
    });
  } catch (ex) {
    callback(ex);
  }
}

Дело в том, что исключение бросается и, соответственно , должно ловиться в том контексте, в котором вызывается функция. В данном примере try/catch и вызов функции бросающей исключение выполнятся в разных контекстах в силу асинхронности функции doSomeAsynchronousOperation.

Answer 7

[ksdaemon]

Согласен с первым комментарием: наиболее логичное место, где хочется использовать try/catch — это например оборачивать запросы через аякс на сервер, но в объекте XmlHttpRequest, да и не только — есть специальные методы типа onerror, в которых если надо можно реализовать обработку неверных ответов. Так что здесь использование try/catch теряет свой смысл. Так что, наверное, этот механизм можно использовать, если вы просто привыкли писать с использованием пользовательских исключений. То есть например проверка формы на валидность данных — проверяете, нашли ошибку, бросили сами исключение, сами его поймали и обработали.
Возможно имеет смысл использовать try/catch при попытках использовать какие-нибудь вещи, доступные в современных браузерах, а в случае их отсутствия делать fallback на что-то простое.

Comments

[Сергей Протько]

По поводу вашего последнего тезиса, обычно какие-то специфичные фичи, которых нету в браузерах, делают через $.support, модернизер ну или, например если нам надо проверить есть ли у браузера поддержка pushState, то просто if( window.history.pushState).

Но буквально недавно у меня была проблема с методом jQuery animate — scrollTop. в IE7 постоянно валились скрипты изза ошибки на уровне jQuery, и тут try/catch пришли на помощь.

[Борис Чумичев]

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

Answer 8

[egorinsk]

Я оборачивал в try/catch (естественно не руками) обработчики событий, вызовы setInterval/setTimeout, коллбеки, чтобы ловить ошибки и оггировать на сервер. Это, по моему, единственное применение, так как в нормальных условиях код не выбрасывает исключений (собственно, потому они и называются исключения).

Answer 9

[dmsx]

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