Styles

mardi 14 mai 2013

Niveaux de Gravité d'une Erreur : Peuvent-ils (doivent-ils) être standardisés ?

Traduction d'un article de Conrad Weisert "Error Severity Levels".

Contexte: les conventions du système d'exploitation

Je viens de lire une longue discussion sur Linked-In sur les niveaux de gravité d'erreur dans un programme, et j'ai été frappé par le sentiment d'une redécouverte des techniques que nous utilisions il y a déjà quelques décennies. Je ne connais pas de livre traitant cette question de manière approfondie, alors permettez-moi d'essayer de commencer. D'abord étudions un peu l'histoire:

1959 : Système d'exploitation de second génération (709-7090)
Le système d'exploitation SHARE (SHARE Operating System - SOS) introduit la notion de niveaux de gravité. Une expression de contrôle d'un batch pouvait spécifier :

- GOIF : Execute uniquement si aucune erreur ou avertissement n'a eu lieu,
- GO : Execute si aucune erreur sérieuse a eu lieu,
- GOGOGO1 : Execute quoi qu'il en soit.

Certains programmes SOS n'observèrent pas ces conventions et certaines installations 709-7090 n'utilisaient pas SOS, mais cette convention inspira les fonctionnalités plus générales des systèmes suivant.

SOS etablit aussi la notion d'interception d'évènements anormaux sous le contrôle du programme, ce qui amena à la gestion des conditions de PL/I, qui à son tour inspira le traitement des exceptions des langages de programmation de la famille C d'aujourd'hui.

1965 : Système d'exploitation de troisième génération
OS/360 systématisa la notion de code de condition applicables à des travaux par lot (batch jobs) de plusieurs étape. Des conventions pour des niveaux de gravité numériques étaient observées par tous les processus système et programmes utilisateurs. Chaque étape d'un job fixait un code retour qui des étapes suivantes peuvent tester avec le Job Control Language (JCL):

00 Aucune erreur n'a eu lieu.
04 Une condition de niveau d'avertissement (trivial) a eu lieu, continuez le traitement,
08 Une erreur sérieuse a eu lieu, supprimez les étapes suivantes dans ce job,
12 Une erreur fatale a eu lieu, terminez l'exécution de ce job immédiatement !

Les codes et ces actions étaient, bien sûr, uniquement des conventions. Vous pouviez mettre en place un job pour faire tout ce que vous vouliez pour n'importe quelle valeur de retour, tant que le programme ne faisait pas ABEND.2


Conventions de programmation

Certaines applications ont étendu les conventions OS/360, en particulier dans le cas des programmes de traitement des transactions. Notre propre entreprise et plusieurs de nos clients ont adopté les conventions suivantes et ont développé une sous-routine standard pour émettre des messages d'erreur de diagnostic, d'abord en PL/I, plus tard en COBOL, et finalement, avec les adaptations nécessaires, en C++ et Java:

1. Lorsqu'il rencontre une erreur, le programme fait un
    CALL SYSERR (lvl, msg);
où le texte de msg suivait la convention demandant à commencer par un identifiant3 qui contenait le nom de la routine d'exécution de l'appel, et le code lvl était un équivalent symbolique d'un des codes conventionnels de retour de JCL.

2. À la fin du programme, une routine de sortie fixait le code de retour OS à la valeur la plus élevée rencontrée pendant l'exécution.

3. Une limite, que le programme pouvait outrepasser, définissait le nombre maximum d'erreurs autorisées pendant l'exécution. Lorsque ce nombre est dépassé, le programme prend fin. Cette fonction est utile pour empêcher un programme hors-contrôle de générer des centaines de pages de sortie incohérentes (par exemple si l'on a accidentellement fourni un programme source à un autre programme attendant un fichier de transactions).

Il y avait d'autres fonctionnalités, mais vous voyez l'idée. Les programmeurs appréciaient l'aide de cette routine, et elle est toujours utilisé dans presque tous les programmes développés dans ces organisations.4

D'autres améliorations évidentes étaient nécessaires pour supporter les programmes multi-thread. Quand une sous-tâche devrait être autorisée à terminer la tâche principale et comment?

D'autres idées?


Faites-nous savoir si vous avez développé ou si vous connaissez une meilleure façon de gérer les erreurs découvertes par les programmes, les messages de diagnostic, et les niveaux de gravité. Quels standard, le cas échéant, seriez-vous prêt à utiliser?

 

1—Dave Farber de Bell Telephone Laboratories appelait ce niveau "GO DAMMIT!" a une conférence SHARE.
2-ABnormal END (fin anormale) : l'action la plus radicale quand une continuation du traitement pourrait causer des dégâts considérables. (En fait, les versions suivantes de l'OS supportaient l'exécution conditionnelle d'étape même si une ABEND a eu lieu, mais les programmeurs prudents évitaient ça).
3-Dans certains langages de programmation cet identifiant peut être généré automatiquement, mais dans la plupart des languages, c'était juste une convention que les programmeurs étaient tenus de se conformer. Cela évitait aux utilisateurs la frustration ressentie lorsqu'ils reçoivent un message mystérieux de, disons, Windows®, indiquant que "le programme spécifié ne peux pas ...".
4- Si vous souhaitez une copie nous contacter à cweisert@acm.org et dites nous pour quel langage et environnement vous en avez besoin.

Aucun commentaire: