try-catch en javascript… n'est-ce pas une bonne pratique?

Il existe une disposition pour le blocage try-catch en javascript . Bien qu'en Java ou dans toute autre langue, la gestion des erreurs soit obligatoire, je ne vois personne les utiliser en javascript dans une plus large mesure. N'est-ce pas une bonne pratique ou simplement nous n'en avons pas besoin en javascript?

Il faut éviter les throwerreurs comme moyen de faire passer les conditions d'erreur dans les applications.

La throwdéclaration ne devrait être utilisée que "Pour que cela ne se produise jamais, plantez et brûlez. Ne récupérez jamais de façon élégante"

try catch Cependant, il est utilisé dans des situations où des objets hôtes ou ECMAScript peuvent générer des erreurs.

Exemple:

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

Dans la communauté node.js , il est recommandé de transmettre les erreurs dans les rappels (car les erreurs ne se produisent que pour les opérations asynchrones) en tant que premier argument.

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

Il y a aussi d'autres problèmes, comme essayer / attraper, c'est très cher et c'est moche et ça ne fonctionne tout simplement pas avec les opérations asynchrones.

Donc, puisque les opérations synchrones ne doivent pas générer d'erreur et que cela ne fonctionne pas avec les opérations asynchrones, personne n'utilise try catch, à l'exception des erreurs renvoyées par des objets hôtes ou par ECMAScript.

Try / catch en Javascript n'est pas aussi sûr que dans d'autres langues, en raison de la nature asynchrone de Javascript. Considérez cet extrait:

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

Le problème est que le sort du flux de contrôle trybloc avant do_something_that_throws()est exécuté, de sorte que l'erreur renvoyée dans la fonction de rappel s'attrapée jamais.

Donc, essayer / attraper est fondamentalement inapproprié dans de nombreux cas, et il n'est pas toujours évident de savoir si quelque chose exécute le code de manière asynchrone ou non. Heureusement, javascript, avec son idiome particulier de rappel asynchrone à un seul thread et sa prise en charge des fermetures réelles, offre une alternative élégante: la gestion des erreurs de type continuation-pass. Il suffit de passer la bonne réponse à toute erreur en tant que fonction, par exemple:

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

Beaucoup de ces réponses sont un peu vieux et ne prennent pas en compte les nouvelles fonctionnalités de ES7 asyncet await.

En utilisant async/ awaitvous pouvez maintenant obtenir un flux de contrôle asynchrone comme vous le souhaitez:

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

En savoir plus sur async/ awaitici . Vous pouvez utiliser async/ awaitmaintenant en utilisant babel .

try-catch en javascript est tout aussi valide et utile que dans tout autre langage qui les implémente. Il y a une raison majeure pour laquelle il n'est pas utilisé autant en javascript qu'en d'autres langues. C'est la même raison pour laquelle javascript est vu comme un langage de script très laid, c'est la même raison pour laquelle les gens pensent que les programmeurs javascript ne sont pas de vrais programmeurs:

• Javascript est une langue incroyablement accessible et omniprésente

Le simple fait que tant de personnes soient exposées à javascript (en raison du seul langage pris en charge par les navigateurs) signifie que vous disposez de beaucoup de code non professionnel. Bien sûr, il y a aussi beaucoup de raisons mineures:

• certaines choses en javascript sont asynchrones et ne catchpeuvent donc pas (trucs asynchrones)
• il y a eu beaucoup de discussions exagérées sur la façon dont try-catch a un énorme impact sur les performances. Il a un peu frappé les performances , mais pour la plupart des codes, cela en vaut la peine.
• (malheureusement) javascript a été implémenté d'une manière qui ignore souvent les erreurs en silence (modification automatique des chaînes en chiffres, par exemple)

Quoi qu'il en soit, try-catch devrait être utilisé, mais bien sûr, vous devriez apprendre à les utiliser correctement - comme tout le reste dans la programmation.

Je crois que la plupart des raisons qui try..catchsont rares en JavaScript sont dues au fait que le langage tolère assez bien les erreurs. La grande majorité des situations peuvent être gérées à l'aide de vérifications de code, de valeurs par défaut correctes et d'événements asynchrones. Dans certains cas, le simple fait d'utiliser un modèle évite les problèmes:

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
}

Certains des problèmes majeurs dans d'autres langues qui provoquent des exceptions n'existent tout simplement pas dans JS. Le typage n'est pas nécessaire la grande majorité du temps. Au lieu de cela, la méthode préférée consiste généralement à vérifier les fonctionnalités (application d'une interface particulière):

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

Avec l'ajout de async/ awaità la langue, try..catchdevient plus répandu. Les promesses étant la forme asynchrone de try..catch, il est logique d'attendre:

doSomething().then(
  doSomethingWithResult,
  doSomethingWithError
)

à la place être écrit comme:

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

Peut-être une autre raison pour laquelle try / catch n'est pas très utilisé en Javascript est que la construction n'était pas disponible dans les toutes premières versions de Javascript ... elle a été ajoutée plus tard.

En conséquence, certains navigateurs plus anciens ne le prennent pas en charge. (En fait, cela pourrait provoquer une erreur d'analyse syntaxique / syntaxique dans certains navigateurs plus anciens, ce qui est plus difficile à "programmer de manière défensive" que la plupart des autres types d'erreur.)

Plus important encore, comme il n'était pas disponible initialement, les fonctions intégrées à Javascript qui ont été initialement publiées (ce que l'on appellerait les fonctions "de bibliothèque" dans de nombreuses langues) ne l'utilisent pas. (Cela ne marche pas très bien pour "attraper" une erreur de someobject.somefunction () si elle ne "jette" pas, mais retourne simplement "null" quand elle rencontre un problème.)

Une autre raison possible est que le mécanisme try / catch ne semblait pas nécessaire au départ (et ne semble toujours pas si utile). Ce n'est vraiment nécessaire que lorsque les appels sont régulièrement imbriqués sur plusieurs niveaux; renvoyer une sorte d'ERRNO fonctionnerait très bien pour les appels directs (bien que pour le rendre vraiment utile chaque fois qu'il est disponible, la meilleure pratique dans la plupart des langues consiste à l'utiliser partout plutôt que sur des appels profondément imbriqués). Comme la logique Javascript devait à l'origine être petite et simple (après tout, c'est simplement un ajout à une page Web :-), les appels de fonction ne devaient pas être profondément imbriqués, et un mécanisme try / catch ne semblait donc pas nécessaire.

Je pense qu'elles ne sont pas très utilisées car le fait de jeter des exceptions dans le code Javascript du côté client rend plus difficile le débogage d'une page.

Plutôt que de jeter des exceptions, je préfère généralement montrer zone d'alerte al, (c. -à alert("Error, invalid...");)

Cela peut sembler étrange, mais des erreurs javascript se produisent côté client. Si un client utilise une page que vous avez créée et que la page génère une exception, à moins que le client ne soit un informaticien averti des technologies, il ne pourra jamais le savoir. vous quel est le problème.

Il vous appellera seulement en vous disant: "Hé, la page X ne marche pas!", Et ce sera à vous de trouver ce qui ne va pas et où se trouve le code.

En utilisant la boîte d'alerte, il est plus probable qu'il appelle et dise quelque chose du genre: "Hé, quand je clique sur le bouton A de la page X, il affiche une boîte qui dit ..." , croyez-moi, ce sera beaucoup plus facile à trouver. l'insecte.