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

Existe uma provisão para o bloco try-catch em javascript . Enquanto em java ou em qualquer outro idioma é obrigatório ter tratamento de erros, não vejo ninguém usando-os em javascript para maior extensão. Não é uma boa prática ou simplesmente não precisamos deles em javascript?

Deve-se evitar throwerros como a maneira de transmitir condições de erro nos aplicativos.

A throwdeclaração deve ser usada apenas "Para que isso nunca aconteça, bata e queime. Não se recupere de forma elegante"

try catch no entanto, é usado em situações em que objetos 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 são que você transmite erros nos 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
})

Também há outros problemas, como o try / catch é muito caro e é feio e simplesmente não funciona 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 usa try catch, exceto os erros gerados pelos objetos host ou pelo ECMAScript

A tentativa / captura no 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 sai do trybloco antes de do_something_that_throws()ser executado, para que o erro gerado dentro do retorno de chamada nunca seja detectado.

Portanto, try / catch é basicamente inadequado em muitos casos, e nem sempre é óbvio se algo executa código de forma assíncrona ou não. Felizmente, o javascript com seu idioma peculiar de retorno de chamada assíncrono com thread único e seu suporte para fechamentos reais fornece uma alternativa elegante: tratamento de erros no estilo de passagem 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 conta os novos recursos asynce do ES7 await.

Usando async/ awaitagora você pode obter um fluxo de controle assíncrono como desejar:

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

Saiba mais sobre async/ awaitaqui . Você pode usar async/ awaitagora usando babel .

try-catch em javascript é tão válido e útil quanto em qualquer outro idioma que os implemente. Há um motivo principal para não ser usado tanto em javascript quanto em outros idiomas. É o mesmo motivo pelo qual o javascript é visto como uma linguagem de script feia, o mesmo motivo pelo qual as pessoas pensam que os programadores de javascript não são programadores de verdade:

• Javascript é uma linguagem incrivelmente acessível e difundida

O simples fato de tantas pessoas serem expostas ao javascript (em virtude do único idioma suportado pelos navegadores) significa que você tem muitos códigos não profissionais por aí. Claro que também existem muitos motivos menores:

• algumas coisas no javascript são assíncronas e, portanto, não são catchcapazes (coisas assíncronas)
• houve muita conversa exagerada sobre como o try-catch tem um enorme impacto no desempenho. Tem um pouco de impacto no desempenho , mas para a maioria dos códigos vale a pena.
• O javascript foi (infelizmente) implementado de uma maneira que geralmente ignora silenciosamente 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 adequadamente - como tudo na programação.

Acredito que muito do motivo try..catchraro no JavaScript seja porque a linguagem tem uma tolerância bastante alta a 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 evitará 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 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 preferido é tipicamente apresentar a verificação (aplicando uma interface específica):

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

Com a adição de async/ awaitpara o idioma, try..catchestá se tornando mais prevalente. Promete ser a forma assíncrona de try..catch, faz sentido que se deva esperar:

doSomething().then(
  doSomethingWithResult,
  doSomethingWithError
)

para ser escrito como:

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

Possivelmente, outro motivo pelo qual o try / catch não é muito usado no Javascript é que o construto não estava disponível nas primeiras versões do Javascript ... foi adicionado mais tarde.

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

Mais importante, como não estava disponível inicialmente, as funções internas do Javascript que foram lançadas inicialmente (o que se chamaria de funções de "biblioteca" em muitos idiomas) não a utilizam. (Ele não funciona muito bem para "capturar" um erro de someobject.somefunction () se não "dispara", mas apenas retorna "nulo" quando encontra um problema.)

Outro motivo possível é que o mecanismo try / catch não parecia necessário inicialmente (e ainda não parece tão útil). É realmente necessário apenas quando as chamadas são aninhadas rotineiramente em vários níveis; apenas devolver algum tipo de ERRNO funcionaria bem para chamadas diretas (embora para torná-lo realmente útil sempre que disponível, a melhor prática na maioria dos idiomas é usá-lo em qualquer lugar, em vez de apenas em chamadas profundamente aninhadas). Como originalmente se esperava que a lógica Javascript fosse pequena e simples (afinal, é apenas um complemento de uma página da web :-), não se esperava que as chamadas de função estivessem profundamente aninhadas e, portanto, um mecanismo de tentativa / captura não parecia necessário.

Acredito que eles não são muito utilizados, porque lançar exceções no código do lado do cliente Javascript torna mais difícil a depuração de uma página.

Em vez de lançar exceções, geralmente prefiro mostrar todas as caixas de alerta (ou seja alert("Error, invalid...");)

Pode parecer estranho, mas erros de Javascript acontecem no lado do cliente, se um cliente estiver usando uma página que você construiu e a página lança uma exceção, a menos que o cliente seja um codificador experiente em tecnologia, não há como ele saber você 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 está 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 inseto.