Lancer des chaînes de caractères au lieu d'erreurs

Question

Puisque nous pouvons lancer n'importe quoi avec le throw en Javascript, ne pouvons-nous pas simplement envoyer directement une chaîne de messages d'erreur ?

Quelqu'un connaît-il des prises dans ce domaine ?

Permettez-moi d'ajouter quelques éléments de contexte : Très souvent, dans le monde JavaScript, les gens s'appuient sur la vérification des paramètres plutôt que d'utiliser le mécanisme try-catch, il est donc logique de ne lancer que les erreurs fatales avec throw . Cependant, pour pouvoir attraper certaines erreurs système, je dois utiliser une classe différente pour mes propres erreurs et, au lieu de créer une sous-classe de Error, je pense que je devrais simplement utiliser String.

Answer 1

Bien que ce soit ok Il est possible de lancer n'importe quelle valeur, mais il est généralement considéré comme mal venu de lancer autre chose qu'une instance de Error ou l'une de ses sous-classes. Il y a plusieurs raisons à cela :

1. Le code de capture peut s'attendre à ce que l'objet lancé ait les caractéristiques habituelles de l'objet. message , stacktrace y name les propriétés qui apparaissent sur Error s.
2. L'absence de trace de la pile rend le débogage problématique, surtout dans le cas d'exceptions non capturées ou de rejets non gérés. Par exemple, le débogage d'une erreur "Uncaught [Object object]" peut être particulièrement pénible.

Answer 2

Oui, vous peut lancer d'autres valeurs mais ce n'est pas une bonne pratique .

Quelqu'un connaît-il des prises dans ce domaine ?

Une chaîne de caractères n'est pas un objet d'erreur, et ne transmet aucune information de débogage utile. Les outils de développement s'appuient sur ces informations, telles que le fichier et la ligne où l'erreur a été créée, la trace de la pile au niveau de l'objet de l'erreur. throw etc., qui sont disponibles en tant que propriétés sur Error objets.

Chaque fois que vous pensez à lancer une valeur de chaîne primitive, lancez un new Error("<the string>") à la place.

Answer 3

Vous pouvez lancer des erreurs avec des messages, vous savez.

try {
    throw new Error("This is an error");
} catch (e) {
    alert(e.message); // This is an error
}

Mais vous peut lancent effectivement des chaînes de caractères :

try {
    throw "This is an error";
} catch (e) {
    alert(e); // This is an error
}

Answer 4

Comme d'autres l'ont mentionné plus haut, si vous ne lancez pas d'objet d'erreur, vous devez avoir des blocs try/catch pour capturer ces objets et les traiter de manière appropriée, sinon vous risquez de vous retrouver dans une situation très difficile pour le débogage.

Cependant, lorsqu'il s'agit de lancer des erreurs à des fins autres que la gestion des erreurs, comme le contrôle du déroulement du programme, cela peut être une façon utile d'utiliser le système throw sans erreur.

L'utilisation de lancers pour contrôler le flux du programme peut s'avérer inefficace dans n'importe quel langage, car le moteur d'exécution doit souvent faire beaucoup d'efforts pour dérouler les informations de la pile d'appels et sérialiser les données afin qu'elles soient disponibles pour l'utilisateur. En évitant la création d'erreurs, vous pouvez éviter ce problème de performance. La clé est que vous devez avoir un gestionnaire en haut de la pile d'appel qui sait comment gérer cette situation. Par exemple, si vous throw {isHardStop: true, stopCode: SOME_CODE} et concevez les gestionnaires pour qu'ils le détectent, vous pourrez peut-être aplatir une partie de votre code ou choisir une syntaxe plus propre.

Votre gestionnaire pour ce cas d'échelle pourrait être structuré comme suit :

try { ... } catch(thr) {
    if(!thr){
       // Is not Error or Json - Handle accordingly
    } else if(thr.isHardStop){
       // Handle the stop
    } else {
       // Most likely a real error. Handle accordingly
    }
}

Answer 5

Bien que vous puissiez lancer n'importe quel type de données, ce n'est pas optimal pour le débogage. A JS Error contient toutes sortes d'informations concernant l'erreur et un message. Alors qu'une chaîne de caractères ne peut contenir qu'un message.

Ces informations supplémentaires comprennent :

1. nom du fichier : à partir de quel fichier l'erreur est survenue
2. Linenumber : à partir de quelle ligne l'erreur est survenue
3. stacktrace : à partir de quelle fonction l'erreur a été appelée

Voici par exemple une trace de pile provenant de chrome devtools :