try-catch em javascript… não é uma boa prática?

Deve-se evitar erros throw como forma de passar condições de erro nas aplicações.

A declaração throw deve ser usada apenas "Para que isso nunca aconteça, quebre e queime. Não recupere com elegância de forma alguma"

try catch no entanto é usado na situação em que objetos do host ou ECMAScript podem gerar erros.

Exemplo:

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

As recomendações na comunidade node.js é que você passa erros em retornos de chamada (porque os erros ocorrem apenas para operações assíncronas) como o primeiro argumento

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
})

Há também outros problemas, como try / catch, que são realmente caros e que são feios e que simplesmente não funcionam com operações assíncronas.

Portanto, como as operações síncronas não devem gerar um erro e não funcionam com operações assíncronas, ninguém utiliza o try catch, exceto os erros lançados pelos objetos do host ou o ECMAScript

O teste / captura em Javascript não é tão à prova de balas quanto em outros idiomas, devido à natureza assíncrona do Javascript. Considere este trecho:

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

O problema é que o fluxo de controle deixa o bloco try antes de do_something_that_throws() ser executado, então o erro lançado dentro do callback nunca é capturado.

Portanto, try / catch é basicamente inapropriado em muitos casos, e nem sempre é óbvio se algo executa código de forma assíncrona ou não. Felizmente, o javascript, com sua peculiar linguagem de retorno de chamada assíncrona com encadeamento único e seu suporte para fechamentos reais, fornece uma alternativa elegante: o tratamento de erros de estilos de continuação. Basta passar a resposta adequada a qualquer erro como uma função, por exemplo:

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

Muitas dessas respostas são um pouco antigas e não levam em consideração os novos recursos do ES7 async e await .

Usando async / await , agora você pode obter um fluxo de controle assíncrono como deseja:

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

Saiba mais sobre async / await here . Você pode usar async / await agora usando o babel .

try-catch em javascript é tão válido e útil quanto em qualquer outro idioma que os implemente. Há uma razão importante pela qual não é usado tanto em javascript quanto em outros idiomas. É a mesma razão pela qual o javascript é visto como uma linguagem de script feia, é a mesma razão pela qual as pessoas acham que os programadores de javascript não são programadores reais:

• O Javascript é uma linguagem incrivelmente acessível e difundida

O simples fato de tantas pessoas estarem expostas ao javascript (em virtude do único idioma suportado pelos navegadores) significa que você tem um monte de código não profissional por aí. Claro que também há muitas razões menores:

• algumas coisas no javascript são assíncronas e, portanto, não são catch able (material assíncrono)
• tem havido muita conversa exagerada sobre como o try-catch tem um grande impacto no desempenho. Tem um pouco de acerto no desempenho , mas para a maioria dos códigos, vale a pena .
• o javascript foi (infelizmente) implementado de forma que silenciosamente ignora os erros (alterando automaticamente as strings para números, por exemplo)

Independentemente disso, o try-catch deve ser usado, mas é claro que você deve aprender como usá-los corretamente - como tudo na programação.

Acredito que grande parte do motivo pelo qual try..catch é raro em JavaScript é porque a linguagem tem uma tolerância bastante alta para erros. A grande maioria das situações pode ser tratada usando verificações de código, bons padrões e eventos assíncronos. Em alguns casos, o simples uso de um padrão evita problemas:

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
}

Alguns dos principais problemas em outros idiomas que causam exceções ocorrem simplesmente não existem no JS. A conversão de tipos não é necessária na grande maioria das vezes. Em vez disso, o método preferencial costuma ser a verificação de recursos (impondo uma interface específica):

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

Com a adição de async / await ao idioma, try..catch está se tornando mais predominante. Promessas sendo a forma assíncrona de try..catch , faz sentido esperar:

doSomething().then(
  doSomethingWithResult,
  doSomethingWithError
)

para ser escrito como:

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

Possivelmente outra razão try / catch não é muito usada em Javascript é a construção não estava disponível nas primeiras versões do Javascript ... foi adicionado mais tarde.

Como resultado, alguns navegadores mais antigos não suportam isso. (Na verdade, isso pode causar um erro de sintaxe / analisador em alguns navegadores mais antigos, algo que é mais difícil de "programar defensivamente" do que a maioria dos outros tipos de erros.)

Mais importante ainda, como não estava disponível inicialmente, as funções de JavaScript embutidas que foram lançadas inicialmente (o que se chama de "biblioteca" funciona em vários idiomas) não fazem uso dela. (Não funciona muito bem "capturar" um erro de someobject.somefunction () se ele não "lançar", mas apenas retorna "null" quando encontra um problema.)

Eu acredito que eles não são muito usados porque lançar exceções no código do lado do cliente Javascript torna mais difícil depurar uma página.

Em vez de lançar exceções, geralmente prefiro mostrar uma caixa de alerta, (por exemplo, alert("Error, invalid..."); )

Pode parecer estranho, mas erros de Javascript acontecem no lado do cliente, se um cliente estiver usando uma página criada e a página lançar uma exceção, a menos que o cliente seja um codificador especializado em tecnologia não é possível que ele seja capaz de dizer qual é o problema.

Ele só ligará para você dizendo: "Ei, a página X não funciona!", e então tudo depende de você descobrir o que deu errado e onde no código .

Ao usar a caixa de alerta, é mais provável que ele ligue e diga algo como: "Ei, quando clico no botão A da página X ele mostra uma caixa que diz ..." , confie em mim, será muito mais fácil encontrar o bug.