Gestion des erreurs d'exécution
Si, pendant l'exécution du programme, une erreur se produit et entraîne l'arrêt de votre programme, le type de message d'erreur suivant est écrit dans le chemin de l'erreur système :
|
PASCAL ERROR #w (texte du message d'erreur) PROCEDURE #x0 PROCEDURE #x1 PROCEDURE #xn LINE NUMBER=y PCODE LOCATION=z |
où :
| Paramètre | Description |
|---|---|
| w | Est le numéro d'erreur s'étant produit. Les numéros d'erreur inférieurs à 100 se réfèrent généralement à des erreurs d'entrée/sortie, tandis que d'autres chiffres font généralement référence à des erreurs de processus. |
| texte du message d'erreur | Est le texte du message extrait du fichier PASCALERRS. Si le fichier PASCALERRS ne peut pas être ouvert ou si le texte approprié est introuvable, cette ligne sera omise. Si l'erreur est une erreur d'entrée/sortie, une deuxième ligne sera généralement affichée donnant un message d'erreur OS-9 relatif à l'erreur d'entrée/sortie. |
| x0, x1 ..., xn | Est une dissociation de l'imbrication des appels de procédure. Il indique que le numéro de procédure "x0" était en cours d'exécution lorsque l'erreur s'est produite, et le "x0" a été appelé par "x1" et ainsi de suite jusqu'à ce que "xn" soit trouvé, étant le premier numéro de procédure ayant commencé l'exécution. Les nombres «x» font référence aux numéros de procédure comme indiqué dans la liste du tableau des procédures. Le numéro de procédure "xn" doit toujours être zéro si la pile n'a pas été détruite. Le même numéro de procédure peut apparaître plusieurs fois dans la liste en cas de récursivité. Si une procédure de code natif fait partie de l'imbrication des appels, elle apparaîtra sous le numéro de procédure 255, quelle que soit la procédure de code natif. Les procédures de code natif perdent leur identité numérique dans le cadre de l'exigence d'être une procédure de code natif. Si l'exécution n'a pas été suffisamment avancée pour qu'une pile d'appels soit construite, ou si la pile d'appels n'est pas valide, soit aucune dissociation ne sera affichée, soit la dissociation peut afficher des numéros de procédure sans signification. |
| y | Est le numéro de ligne du programme source où l'erreur s'est produite. Si le numéro de la ligne source commence par le mot-clef "END" ou "ELSE", il est possible que l'erreur se soit réellement produite dans le code de la ligne source significative précédente suivante, ou que l'erreur se soit réellement produite dans le code de terminaison quel que soit le type de instruction composée que le "END" ou "ELSE" se termine. Cette ligne d'erreur n'est donnée que si vous avez activé l'inclusion des numéros de ligne source dans le programme source. Comme pour les lignes d'erreur précédentes, cette ligne n'est signalée que si l'exécution s'est déroulée suffisamment loin pour qu'un numéro de ligne valide soit connu. De plus, si l'inclusion du numéro de ligne est activée et désactivée de manière sélective dans le programme source, cette ligne d'erreur affiche le dernier numéro de ligne source connu. |
| z | Est l'emplacement du P-Code dans la procédure "x0" étant en cours d'exécution lorsque l'erreur s'est produite. Là où le message de numéro de ligne peut vous amener rapidement à proximité de l'énoncé du problème, l'emplacement du P-Code peut vous donner une idée de l'endroit où le problème s'est produit dans une instruction. Comme pour les lignes d'erreur précédentes, cette ligne n'est signalée que si l'exécution s'est déroulée suffisamment loin pour qu'un emplacement P-Code valide soit connu. De plus, il y a plusieurs erreurs pouvant se produire pour lesquelles les informations de localisation du P-Code sont perdues, auquel cas cette ligne n'apparaîtra pas. Plus particulièrement, de nombreuses erreurs d'entrée/sortie et l'erreur de débordement de multiplication d'adresse font que les informations d'emplacement du P-Code sont inconnues au moment du rapport d'erreur. Les programmes en étant à leurs premiers stades de test devraient probablement faire en sorte que les numéros de ligne soient inclus dans le fichier P-Code pour faciliter le débogage et les tests. Au fur et à mesure que le programme devient plus fiable et sans erreur, vous pouvez empêcher l'inclusion de numéro de ligne pour obtenir une exécution légèrement améliorée et une efficacité de la mémoire - en vous appuyant uniquement sur le rapport d'emplacement du P-Code à des fins de débogage supplémentaires. |
La plupart des erreurs d'abandon sont divisées en deux classes : entrées/sorties et mathématiques. Si une erreur d'abandon est dans l'une de ces deux classes, son alimentation peut être désactivée via les procédures standard IOABORT ou MATHABORT. Les fonctions standard IORESULT et MATHRESULT sont fournies afin que vous puissiez traiter de telles erreurs dans le programme. Certains programmeurs pensent que vous ne devriez jamais désactiver les vérifications du système pour les erreurs d'entrées/sorties ou mathématiques. Si vous faites partie de ceux-ci, n'utilisez simplement aucune des procédures standard mentionnées ci-dessus. Si, cependant, vous êtes d'avis que les programmes de production doivent être écrits avec l'idée qu'ils ne doivent jamais être interrompus par le système, quelles que soient les ordures que l'utilisateur envoie au programme, que le programme doit signaler intelligemment la nature de l'entrée erronée, et, si nécessaire, arrêtez gracieusement, alors les fonctions et procédures standard ci-dessus peuvent être d'un grand avantage.
Il existe cependant quelques erreurs interrompant toujours votre programme de manière inconditionnelle. Une erreur de sélection de cas en est une. Cette erreur se produit lorsqu'une instruction case est exécutée mais qu'aucune instruction n'a une liste de sélection constante contenant la valeur de sélection requise. Par exemple :
provoquerait un abandon de l'exécution car la valeur réelle de la variable i, étant 5 dans ce cas, n'apparaît dans aucune liste de sélection de constantes. Une des deux actions peut être entreprise pour éviter ce type d'erreur - soit assurez-vous que toutes les valeurs possibles de l'expression de sélection sont prises en compte dans les listes de sélection de constantes, ou utilisez l'option d'instruction de cas OTHERWISE comme dans :
Les erreurs de dépassement de pile et de tas abandonnent également un programme de manière inconditionnelle. L'utilisation des options d'exécution peut éliminer ces erreurs sur les options d'exécution. Les erreurs de débordement multiplié par adresse annulent également inconditionnellement un programme, mais cela, ainsi que toute autre erreur d'abandon inconditionnel, peut être évité par de bonnes pratiques de programmation. Le système OS-9 Pascal est destiné à fournir la capacité d'écrire des programmes étant aussi conviviaux et tolérants que possible et les erreurs restantes interrompant toujours sans condition un programme le font parce qu'il n'est pas possible de récupérer intelligemment de la condition d'erreur et poursuivre l'exécution du programme.
Lorsque vous utilisez IOABORT et MATHABORT, il est préférable de désactiver le processus d'abandon pour le plus petit intervalle de code nécessaire. Par exemple :
est un bon moyen de vérifier si un fichier existe déjà. Si le fichier n'existe pas, la variable i contiendra le numéro 216 étant le numéro d'erreur OS-9 pour une tentative d'ouverture d'un fichier inexistant. Si aucune erreur n'a été rencontrée lors de la tentative d'ouverture du fichier, la variable «i» contiendra le numéro 0. N'oubliez pas que si plusieurs erreurs sont rencontrées pour un fichier entre l'appel IOABORT désactivant le processus d'abandon et l'appel IOABORT réactivant le processus d'abandon, seul le premier numéro d'erreur est renvoyé - les autres sont perdus. Le contraire est vrai pour les erreurs mathématiques - seul le dernier numéro d'erreur est conservé, les autres sont perdus. Par exemple :
- mathabort(false);
- i:=32767+16000*16000+2;
- mathabort(true);
- j: =mathresult;
définira la variable «j» sur le numéro 199, indiquant un débordement d'entier lors de l'ajout, de la soustraction ou de l'annulation. L'erreur provoquée par le débordement d'entier pour la multiplication est perdue puisque l'opération d'ajout ayant également provoqué un débordement s'est produite en dernier. Si, dans l'exemple ci-dessus, le débordement de multiplication a provoqué le résultat du module étant retenu comme étant un nombre négatif, il est probable qu'aucun débordement sur l'addition, la soustraction ou la négation ne se serait produit. Dans ce cas, la variable "j" serait définie sur le nombre 184, indiquant un dépassement de capacité de multiplication. Gardez à l'esprit la combinaison possible d'événements pouvant se produire et les résultats possibles pour toutes ces combinaisons lors de l'utilisation de IORESULT et MATHRESULT. Souvenez-vous également que chaque fois que vous appelez IORESULT ou MATHRESULT, le numéro d'erreur du fichier approprié ou du résultat mathématique est remis à zéro. Vous devez enregistrer une copie du numéro d'erreur du dernier appel si vous avez l'intention de l'utiliser plusieurs fois.