8
votes

Quelle est la position la plus correcte pour l'argument d'erreur dans un rappel JavaScript?

J'écris une fonction JavaScript qui prend un rappel. Le rappel sera adopté un argument d'erreur si quelque chose ne va pas.

Quels sont les conventions d'appel les meilleurs / la plus standard?

  • Si l'argument d'erreur du rappel soit le premier ou le dernier?
  • dois-je passer un 'errorormsg' string ou a nouvelle erreur ('errorormsg') objet?

    c'est-à-dire, qu'est-ce qui est plus correct - ce code: xxx

    ou ce code: xxx

    ou ceci: xxx

    Si c'est pertinent, mon code sera utilisé à la fois comme module NodeJS et en tant que bibliothèque JavaScript basée sur le navigateur. >


0 commentaires

4 Réponses :


7
votes

Vous pouvez spécifier deux rappels, un pour le succès et celui de l'erreur, Â et les deux encapsulés dans un seul argument "Callbacks". C'est le nombre de bibliothèques JavaScript gérant votre besoin. XXX

Les fonctions de réussite et d'erreur sont facultatives. Pour spécifier les deux, appelez-le comme ceci: xxx

Vous pouvez également faire cela: xxx

Si vous le souhaitez, vous Peut élargir l'objet Callbacks pour supporter d'autres scénarios, tels que "Terminé".


1 commentaires

Ceci est courant dans les bibliothèques Web JS, mais pas dans Node.js.



1
votes

Vous devez choisir une convention pour votre bibliothèque et coller avec elle; Sinon, c'est arbitraire. Il existe de nombreuses façons différentes de manipuler des erreurs dans JavaScript:

  1. Prenant à la fois un "succès" et "Erreur" rappel.
  2. Prendre un seul rappel pour gérer les cas "Success" et "Erreur".
  3. Ayant un mécanisme d'enregistrement pour un gestionnaire de "erreur" par défaut, faisant des manutentionnaires d'erreur optionnels sur tous les autres appels, à l'aide des rappels d'erreur immédiate ou de repli, selon le cas.

    combiné avec:

    1. n'utilisant aucun paramètre sur le rappel d'erreur.
    2. en utilisant un booléen pour indiquer le succès / l'échec.
    3. en utilisant une chaîne pour encapsuler la nature de l'erreur.
    4. en utilisant un objet "Résultat" plus complexe pour encapsuler le succès / l'échec et le résultat.
    5. en utilisant un objet complexe pour encapsuler des informations de défaillance détaillées.

      Vraiment, c'est entièrement à vous de décider. Cela dépend également de ce que vous essayez de faire. Par exemple, si vous n'avez pas vraiment l'intention de faire quelque chose avec les informations de défaillance, cela ne vaut peut-être pas la charge de construire / passer autour de cette information supplémentaire. Mais vous avez peut-être beaucoup d'informations détaillées sur l'échec que vous souhaitez transmettre à l'utilisateur ou à l'appelant de l'API, auquel cas il fait beaucoup de sens.

      Choisissez une convention et coller avec elle. Autre que cela, c'est entièrement à vous.


0 commentaires


0
votes

semble que nous n'avons pas de réponse moderne ici :)

Vous pouvez maintenant utiliser la promesse pour cela: xxx

ou plus simple, si l'action est synchrone: xxx

puis, pour gérer le résultat: xxx

xxx

Donc, au cas où il n'y avait pas de rappel d'erreur (résultat) (résultat) ne sera effectué, en cas d'erreur ErrorHandler («TROZ PAS séparément. Bel exemple de séparation des préoccupations.


0 commentaires