попробуй поймай в javascript… разве это не хорошая практика?

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

Следует избегать throwошибок как способа передачи условий ошибок в приложениях.

throwЗаявление должно быть использовано только «Для этого не должно произойти, аварии и сжечь. Не восстанавливайте элегантно в любом случае»

try catch однако используется в ситуации, когда хост-объекты или ECMAScript могут выдавать ошибки.

Пример:

var json
try {
    json = JSON.parse(input)
} catch (e) {
    // invalid json input, set to null
    json = null
}

В сообществе node.js рекомендуется, чтобы вы передавали ошибки в обратных вызовах (поскольку ошибки возникают только для асинхронных операций) в качестве первого аргумента.

fs.readFile(uri, function (err, fileData) {
    if (err) {
        // handle
        // A. give the error to someone else
        return callback(err)
        // B. recover logic
        return recoverElegantly(err)
        // C. Crash and burn
        throw err
    }
    // success case, handle nicely
})

Есть и другие проблемы, такие как try / catch очень дорого, уродливо и просто не работает с асинхронными операциями.

Так как синхронные операции не должны выдавать ошибку и не работают с асинхронными операциями, никто не использует try catch, кроме ошибок, генерируемых объектами хоста или ECMAScript

Try / catch в Javascript не так пуленепробиваем, как в других языках, из-за асинхронной природы Javascript. Рассмотрим этот фрагмент:

try {
    setTimeout(function() {
        do_something_that_throws();
    }, 1000);
}
catch (e) {
    alert("You won't see this!");
}

Проблема заключается в том, что поток управления покидает tryблок до того, как do_something_that_throws()будет выполнен, поэтому ошибка, генерируемая внутри обратного вызова, никогда не перехватывается.

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

setTimeout(function () {
    do_something_that_calls_err(function(err) {
        alert("Something went wrong, namely this: " + err);
    }),
    1000);

Многие из этих ответов устарели asyncи не учитывают новые функции ES7 и await.

Используя async/ awaitвы можете теперь получить асинхронный поток управления, как вы хотите:

async function email(address) {
  try {
    // Do something asynchronous that may throw...
    await sendEmail({ to: address, from: 'noreply@domain.com`, subject: 'Hello' })
  } catch(err) {
    if (err instanceof SomeCustomError) {
      elegantlyHandleError(err)
    } else {
      throw err
    } 
  }
})

Узнайте больше о async/ awaitздесь . Вы можете использовать async/ awaitсейчас, используя Babel .

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

• Javascript - это невероятно доступный и распространенный язык

Сам факт того, что так много людей подвергаются воздействию javascript (благодаря тому, что браузеры поддерживают только поддерживаемый язык), означает, что у вас есть много непрофессионального кода. Конечно, есть также много незначительных причин:

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

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

Я полагаю, что большая часть причины, которая try..catchредко встречается в JavaScript, заключается в том, что язык имеет довольно высокую устойчивость к ошибкам. Подавляющее большинство ситуаций может быть обработано с помощью проверок кода, правильных значений по умолчанию и асинхронных событий. В некоторых случаях простое использование шаблона предотвратит проблемы:

function Foo() {
    //this may or may not be called as a constructor!!
    //could accidentally overwrite properties on window
}

function Bar() {
    if (!(this instanceof Bar)) {
        return new Bar();
    }
    //this will only work on Bar objects, and wont impact window
}

Некоторые из основных проблем в других языках, которые вызывают исключения, просто не существуют в JS. В большинстве случаев кастинг не требуется. Вместо этого предпочтительным методом обычно является проверка функций (принудительное использование определенного интерфейса):

function doFoo(arg) {
    if (arg.foo) {
        arg.foo();
    } else {
        Bar.prototype.foo.call(arg);
    }
}

С добавлением async/ awaitк языку try..catchстановится все более распространенным. Обещания, являющиеся асинхронной формой try..catch, имеют смысл ожидать:

doSomething().then(
  doSomethingWithResult,
  doSomethingWithError
)

вместо этого быть написано как:

try {
  const result = await doSomething()
  doSomethingWithResult(result)
} catch (e) {
  doSomethingWithError(e)
}

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

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

Что еще более важно, поскольку он изначально не был доступен, встроенные функции Javascript, которые были первоначально выпущены (то, что на многих языках называлось бы «библиотечными» функциями), не используют его. (Он не очень хорошо «ловит» ошибку от someobject.somefunction (), если он не «выбрасывает», а вместо этого просто возвращает «ноль» при возникновении проблемы.)

Еще одной возможной причиной является то, что механизм try / catch изначально не казался необходимым (и все же он не кажется таким уж полезным). Это действительно необходимо, только когда вызовы обычно вложены в несколько уровней; простое возвращение какого-либо типа ERRNO прекрасно подойдет для прямых вызовов (хотя, чтобы сделать его действительно полезным, когда он доступен, в большинстве языков рекомендуется использовать его везде, а не только при глубоко вложенных вызовах). Поскольку изначально логика Javascript должна была быть небольшой и простой (в конце концов, это просто дополнение к веб-странице :-), не ожидалось, что вызовы функций будут глубоко вложенными, и поэтому механизм try / catch не кажется необходимым.

Я полагаю, что они не используются так часто, потому что выбрасывание исключений в клиентском коде Javascript затрудняет отладку страницы.

Вместо того , чтобы бросать исключения, я обычно предпочитаю , чтобы показать окно предупреждения аль (то есть alert("Error, invalid...");)

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

Он только позвонит вам и скажет: «Эй, страница X не работает!», И тогда вам остается только выяснить, что пошло не так и где в коде.

Используя вместо этого окно с предупреждением, более вероятно, что он звонит и говорит что-то вроде: «Эй, когда я нажимаю на кнопку A на странице X, появляется окно с надписью ...» , поверьте мне, это будет намного легче найти баг.