Résumé de l'utilisation des erreurs générées par JS

Cette fois, je vais vous apporter un résumé de l'utilisation des erreurs de lancement JS et quelles sont les précautions pour les erreurs de lancement JS. Voici des cas réels, jetons un coup d'œil.

Lancer des erreurs en JS est un art. Il faut du temps pour déterminer où dans le code il convient de générer une erreur. Ainsi, une fois que vous aurez compris cela, votre temps de débogage de votre code sera beaucoup plus court et votre satisfaction à l'égard de votre code augmentera considérablement.

La nature de l'erreur

Un programme génère une erreur lorsque quelque chose d'inattendu se produit. Peut-être qu'une valeur incorrecte a été transmise à une fonction ou qu'une opération mathématique a rencontré un opérande non valide. Les Langages de programmation définissent un ensemble de règles de base, les écarts par rapport à ces règles provoqueront des erreurs et les développeurs pourront alors corriger le code. Le débogage est très difficile si les erreurs ne vous sont pas générées ou signalées. Si toutes les pannes sont silencieuses, le premier problème est qu’il faudra beaucoup de temps pour les trouver, sans parler de les isoler et de les réparer. Par conséquent, les erreurs sont les amies du développeur, pas son ennemi.

Les erreurs apparaissent souvent à des endroits inattendus et à des moments inappropriés, ce qui est très gênant. Pire encore, les messages d’erreur par défaut sont souvent trop concis pour expliquer exactement ce qui n’a pas fonctionné. Les messages d'erreur JS sont connus pour être clairsemés et énigmatiques (en particulier dans les anciennes versions d'IE), ce qui ne fait qu'aggraver le problème. Imaginez si une erreur apparaissait indiquant : "Cet appel de fonction a échoué car ces conditions se sont produites." Ensuite, la tâche de débogage devient immédiatement plus facile, ce qui présente l'avantage de générer vos propres erreurs.

Il est très utile de penser aux erreurs telles que les cas d'échec intégrés. Il est beaucoup plus facile de planifier un échec à un endroit spécifique de votre code que de s'attendre à un échec partout. Il s’agit d’une pratique très courante dans la conception de produits, et pas seulement dans le codage. Les voitures disposent également de zones d'absorption des chocs où le châssis est conçu pour s'effondrer de manière prévisible en cas d'impact. En sachant comment ces cadres réagiront en cas d'accident - en particulier quelles pièces tomberont en panne - les fabricants seront en mesure d'assurer la sécurité des passagers. Votre code peut également être créé de cette façon.

Lancer des erreurs dans JS

Il ne fait aucun doute que lancer des erreurs dans JS est plus précieux que de faire la même chose dans n'importe quel autre langage, et cela est dû aux inconvénients du débogage côté Web Complexité. Vous pouvez utiliser l'opérateur throw pour lancer un objet fourni comme une erreur. Des objets de tout type peuvent être générés comme des erreurs, cependant, les objets Error sont les plus couramment utilisés.

throw new Error('Something bad happened.');

Le type Error intégré est valide dans toutes les implémentations JS. Son constructeur n'accepte qu'un seul paramètre, qui fait référence au message d'erreur. Lorsqu'une erreur est générée de cette manière, le navigateur affiche généralement le message (chaîne de message) directement s'il n'est pas détecté par une instruction try-catch. La plupart des navigateurs disposent aujourd'hui d'une console, où les messages d'erreur seront affichés lorsqu'une erreur se produit. En d’autres termes, toutes les erreurs que vous lancez et celles que vous ne lancez pas sont traitées de la même manière.

Les développeurs inexpérimentés renvoient parfois directement une chaîne comme une erreur, telle que :

// 不好的写法throw 'message';

Cela génère effectivement une erreur, mais tous les navigateurs ne le font pas. Les réponses seront comme vous l'attendez. Firefox, Opera et Chrome afficheront tous un message « exception non interceptée » et contiendront la chaîne de message ci-dessus. Safari et IE génèrent simplement une erreur « exception non interceptée » sans fournir du tout la chaîne de message ci-dessus, ce qui n'est pas utile pour le débogage.

Évidemment, vous pouvez lancer n'importe quel type de données si vous le souhaitez. Il n'y a pas de contrainte de règle qui ne puisse pas être un type de données spécifique.

throw { name: 'Nicholas' };throw true;throw 12345;throw new Date();

Une chose à garder à l'esprit est que toute valeur lancée générera une erreur si elle n'est pas capturée par une instruction try-catch. Firefox, Opera et Chrome appelleront tous la fonction String() sur la valeur renvoyée pour compléter la logique d'affichage du message d'erreur, mais ce n'est pas le cas avec Safari et IE. Pour tous les navigateurs, le seul moyen sans erreur d’afficher un message d’erreur personnalisé consiste à utiliser un objet Error.

Avantages de lancer des erreurs

Lancer vos propres erreurs vous permet d'utiliser le texte exact que le navigateur doit afficher. En plus des numéros de ligne et de colonne, vous pouvez inclure toutes les informations dont vous avez besoin pour déboguer le problème. Je recommande de toujours inclure le nom de la fonction dans le message d'erreur, ainsi que la raison pour laquelle la fonction a échoué. Considérez la fonction suivante :

function getDivs (element) {  return element.getElementsByTagName('div');
}

Cette fonction est conçue pour obtenir les éléments div parmi tous les éléments descendants sous l'élément element. Il peut être courant de transmettre une valeur nulle à un élément DOM qui est transmis à une fonction sur laquelle opérer, mais ce qui est en réalité requis, c'est un élément DOM. Que se passe-t-il si vous transmettez null à cette fonction ? Vous verrez un vague message d'erreur similaire à "objet attendu". Ensuite, vous devez examiner la pile d'exécution et localiser le problème dans le fichier source. Le débogage est plus facile en lançant une erreur :

function getDivs (element) {  if (element && element.getElementsByTagName) {    return element.getElementsByTagName('div');
  } else {    throw new Error('getDivs(): Argument must be a DOM element.');
  }
}

现在给getDivs()函数抛出一个错误，任何时候只要element不满足继续执行的条件，就会抛出一个错误明确地陈述发生的问题。如果在浏览器控制台中输出该错误，你马上能开始调试，并知道最有可能导致该错误的原因是调用函数试图用一个值为null的DOM元素去做进一步的事情。

我倾向于认为抛出错误就像给自己留下告诉自己为什么失败的标签。

何时抛出错误

理解了如何抛出错误只是等式的一个部分，另外一部分就是要理解什么时候抛出错误。由于JS没有类型和参数检查，大量的开发者错误地假设他们自己应该实现每个函数的类型检查。这种做法并不实际，并且会对脚本的整体性能造成影响。考察下面的函数，它试图实现充分的类型检查。

// 不好的做法：检查了太多的错误function addClass (element, className) {  if (!element || typeof element.className !== 'string') {    throw new Error('addClass(): First argument must be a DOM element.');
  }  if (typeof className !== 'string') {    throw new Error('addClass(): Second argument must be a string.');
  }
  element.className += '' + className;
}

这个函数本来只是简单地给一个给定的元素增加一个CSS类名（className），因此，函数的大部分工作变成了错误检查。纵然它能在每个函数中检查每个参数（模仿静态语言），在JS中这么做也会引起过度的杀伤。辨识代码中哪些部分在特定的情况下最有可能导致失败，并只在那些地方抛出错误才是关键所在。

在上例中，最有可能引发错误的是给函数传递一个null引用值。如果第二个参数是null或者一个数字或者一个布尔值是不会抛出错误的，因为JS会将其强制转换为字符串。那意味着导致DOM元素的显示不符合期望，但这并不至于提高到严重错误的程度。所以，我只会检查DOM元素。

// 好的写法function addClass (element, className) {  if (!element || typeof element.className !== 'string') {    throw new Error('addClass(): First argument must be a DOM element.');
  }
  element.className += '' + className;
}

如果一个函数只被已知的实体调用，错误检查很可能没有必要（这个案例是私有函数）；如果不能提前确定函数会被调用的所有地方，你很可能需要一些错误检查。这就更有可能从抛出自己的错误中获益。抛出错误最佳的地方是在工具函数中，如addClass()函数，它是通用脚本环境中的一部分，会在很多地方使用，更准确的案例是JS类库。

针对已知条件引发的错误，所有的JS类库都应该从它们的公共接口里抛出错误。如jQuery、YUI和Dojo等大型的库，不可能预料你在何时何地调用了它们的函数。当你做错事的时候通知你是它们的责任，因为你不可能进入库代码中去调试错误的原因。函数调用栈应该在进入库代码接口时就终止，不应该更深了。没有比看到由一打库代码中函数调用时发生一个错误更加糟糕的事情了吧，库的开发者应该承担起防止类似情况发生的责任。

私有JS库也类似。许多Web应用程序都有自己专用的内置的JS库或“拿来”一些有名的开源类库（类似jQuery）。类库提供了对脏的实现细节的抽象，目的是让开发者用得更爽。抛出错误有助于对开发者安全地隐藏这些脏的实现细节。

这里有一些关于抛出错误很好的经验法则：

一旦修复了一个很难调试的错误，尝试增加一两个自定义错误。当再次发生错误时，这将有助于更容易地解决问题。

如果正在编写代码，思考一下：“我希望[某些事情]不会发生，如果发生，我的代码会一团糟糕”。这时，如果“某些事情”发生，就抛出一个错误。

如果正在编写的代码别人（不知道是谁）也会使用，思考一下他们使用的方式，在特定的情况下抛出错误。

请牢记，我们目的不是防止错误，而是在错误发生时能更加容易地调试。

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

jscss基础操作总结

为什么web开发中需要避免使用全局变量

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!