Une analyse approfondie de l'instruction try catch en JS et de ses deux fonctions !

Cet article vous présentera l'instruction try catch en Javascript et présentera les deux fonctions de l'instruction try catch. J'espère qu'elle vous sera utile !

Le programme est exécuté séquentiellement de haut en bas, en même temps, la route d'exécution peut être modifiée via certaines instructions de contrôle, la route d'exécution finale du programme est le flux de contrôle.

Les instructions de contrôle en js incluent if, for, while, try catch, etc. Elles changeront toutes la direction du programme.

Les programmes fonctionnent sur des données. Les données qui changent au fur et à mesure de l'exécution du programme, c'est-à-dire à mesure que le flux de contrôle avance, sont appelées flux de données.

Évidemment, le flux de données dépend du flux de contrôle. L'analyse du flux de données dans l'analyse de programme nécessite également d'abord une analyse du flux de contrôle.

Par exemple, ce morceau de code :

const a = 1;
let b;

if (a === 1) {
    b = '1111';
} else {
    b = '2222';
}

Parce que a vaut 1, il sera exécuté pour b = '1111'; Il s'agit du flux de contrôle, qui est le code finalement exécuté par le programme. Il peut être utilisé pour analyser la direction de. le programme et effectuez une suppression de code mort, etc.

Au fur et à mesure que le flux de contrôle est exécuté, b se verra attribuer une valeur de 2222. Il s'agit du flux de données, c'est-à-dire le processus de modification de la valeur, qui peut être utilisé pour analyser la valeur de la variable d'une certaine instruction.

Le programme effectue un traitement différent pour différentes données. Si les données comportent des erreurs, le programme de traitement ne pourra pas les traiter et une erreur sera signalée, ce qui interrompra le flux de contrôle ultérieur. Par exemple, les données sont vides, le format des données est incorrect, etc. À ce stade, la gestion des erreurs doit être effectuée via try catch, également appelée gestion des exceptions.

Nous traitons les exceptions dans deux buts :

• Pour effectuer un traitement approfondi de la mauvaise logique.

Par exemple, lorsqu'il y a une erreur dans l'analyse des paramètres, attribuez une valeur par défaut dans le catch. Une fois cette erreur traitée, il n’est pas nécessaire de la signaler à nouveau. Dans ce cas, try catch fait également partie de la logique, équivalent à if else.

• Fournissez une description plus basée sur un scénario de l'erreur signalée.

Les erreurs JS sont générées par le moteur JS. Par exemple, l'appel d'une méthode sur un objet nul signalera une TypeError, et l'utilisation d'une variable non déclarée signalera une ReferenceError. L'erreur spécifique est signalée dans différents scénarios et a des significations différentes :

Si cet objet provient d'une entrée utilisateur, alors il y a une erreur dans l'entrée utilisateur. Si cet objet est obtenu du serveur, cela signifie que les données sont renvoyées par. le serveur est incorrect. Dans différents scénarios, la même erreur aura des significations plus spécifiques, nous devons donc essayer de catch. Ensuite, lancez une erreur personnalisée contenant une description de l'erreur avec des informations sur la scène.

De nombreuses bibliothèques et frameworks le font bien. Les erreurs signalées contiennent des informations de scénario spécifiques et même des solutions. Certaines sont gérées via des numéros d'erreur. Vous pouvez interroger les solutions via errorno. Il s’agit d’une gestion personnalisée des erreurs.

De nombreuses erreurs signalées dans les codes métiers ne sont pas traitées de cette manière, mais l'erreur native est signalée directement. Nous utiliserons la plate-forme de surveillance des exceptions pour collecter certaines erreurs générées globalement, et ces erreurs sont souvent des informations relativement primitives. Bien que l'emplacement et la pile des erreurs soient fournis, nous devons toujours examiner le code source pour localiser le problème.

Par exemple, une erreur est signalée selon laquelle un objet est vide, mais comment savoir quel objet est vide, quelle en est la raison, comment le résoudre et s'il a un numéro.

Ce serait bien mieux si nous pouvions détecter diverses erreurs, puis lancer des erreurs personnalisées pour des scénarios spécifiques. Les bibliothèques tierces ont fait du bon travail à cet égard, mais peu de personnes travaillant dans le code métier prêtent attention aux erreurs personnalisées basées sur des scénarios.

Bien sûr, les utilisateurs du code commercial frontal utilisent le logiciel via l'interface. En fait, il leur suffit de fournir quelques invites d'interface utilisateur pour diverses erreurs. Étant donné que le code de la bibliothèque est destiné aux développeurs, il est nécessaire de décrire diverses erreurs de manière basée sur des scénarios, voire de numéroter les erreurs et de proposer des solutions.

Mais je pense que le code métier devrait également traiter les erreurs comme le code d'une bibliothèque tierce. Ne signalez pas les erreurs natives dénuées de sens, mais signalez certaines erreurs personnalisées avec des significations spécifiques, afin que le dépannage et la résolution des problèmes soient très simples.

Cependant, bien que les erreurs personnalisées basées sur des scénarios puissent mieux aider à résoudre les problèmes, elles doivent être basées sur la certitude des erreurs qui peuvent être signalées par le code. Si le message d'erreur que vous signalez est différent de la cause réelle de l'erreur, cela augmentera la difficulté du dépannage. Il est préférable de signaler l'erreur d'origine.

Résumé

Le processus d'exécution du programme est le flux de contrôle. Affectées par les instructions de contrôle, les données seront modifiées pendant l'exécution. Les modifications des données sont appelées flux de données. Le flux de contrôle et le flux de données sont deux aspects qui sont souvent analysés. analyse du programme.

Les erreurs interrompront le flux de contrôle. Nous devons effectuer un traitement sur les erreurs via try catch.

La gestion des erreurs a deux objectifs :

L'un consiste à effectuer un traitement secret, ce qui équivaut à if else, et il n'est plus nécessaire de signaler les erreurs.

La première consiste à fournir une description basée sur un scénario des erreurs JS natives et à créer un objet d'erreur avec des informations plus spécifiques à générer.

De nombreuses bibliothèques le font très bien et donnent même des numéros d'erreur et des solutions. Mais en fait, une grande partie du code métier fournit uniquement des commentaires aux utilisateurs sur l'interface utilisateur et ne fournit pas de packaging basé sur des scénarios pour les erreurs générées. Il en résulte que les erreurs collectées par la plateforme de surveillance des erreurs sont des erreurs relativement primitives et que le code source doit être visualisé pour le dépannage. Si vous pouvez également créer un package d'erreurs basé sur des scénarios, comme le code de la bibliothèque, il sera beaucoup plus facile de compter et de résoudre les problèmes, ce que la plupart des ingénieurs Javascript n'ont pas fait.

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéos de programmation ! !

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!