Gestion d'erreur lisaac

Je suis totalement en phase avec cette dernière approche, c'est une des raisons pour laquelle je m'interesse à lisaac.

Pour les break/return ..., je ne suis pas certain que l'on puisse l'assimiler à un goto qui est explicitement une mauvaise pratique, je l'assimilerai plus à une simplification de conditionnelles imbriquées, pratique de mon point de vue saine, d'ailleurs die_with_code() existe et effectue cette action bien au delà du bloc puisqu'il s'agit de la sortie intégrale du programme.
Mais il semble s'agir effectivement d'un choix conceptuel déjà tranché, aussi je ne reviendrais plus dessus.

Je souhaiterai par contre revenir sur la gestion d'erreur de manière plus générale. Contexte dans lequel les exceptions fournissent une solution élégante à la problématique :
1. La gestion d'erreur ne devrait pas être attaché uniquement à une phase debug, nombre de circonstances provoquent des erreurs, souvent lié au logiciel ou matériel sous-jacent, donc difficilement contrôlable et anticipable.
Prenons l'exemple de lisaac qui s'appuie sur des lib C, en cas d'erreur de la lib, lisaac devrait fournir un mécanisme permettant de trapper l'erreur et prendre la décision adéquat. Quelques types par defaut existent généralement (erreur de contrainte, Div/0, systeme, ...) .
Un de mes premiers tests lisaac a été l'utilisation de la ligne de commande, étonnant non ;-) ...; en itérant un cran trop loin (trop classique...), j'ai eu le droit à un magnifique core dump... . Je m'attendais plutot à erreur de contrainte ou erreur de Fctn sous-jacentes beaucoup plus explicite.

2. Le traitement d'erreur n'est pas forcement réalisé au même niveau que la détection et de survenance de l'évènement.. Il est donc nécessaire de pouvoir remonté la pile des appels.
Dans un système complexe, toutes les interactions ne sont pas forcement déterministe (en particulier quand on s'interface avec des éléments externes, il est alors pertinent d'avoir un mécanisme générique et simple d'emploi sans devoir spécifier à tous les étages les types d'erreurs attendus ... ;-)

3. Afin d'être traiter convenablement, l'information de contexte d'erreur doit exister au moment du traitement.

4. Une exception doit pouvoir remonter la pile d'exécution, jusqu'à son traitement éventuel.Si ce n'est le cas, le programme s'arrête avec sa pile d'exécution classique.

Dans ce contexte, Lisaac possède quelques embryons intéressants :
1. La programmation par contrat couvre effectivement bien la partie déclenchement d'exception à condition que l'on puisse ajouter un contrat sur affection de valeur et non uniquement en pre et post condition. Dans ce cas, de manière déclarative, il est possible d'exprimer une contrainte qui sera sujette à erreur et donc déclenchement d'exception.

Un exemple classique simpliste, la lecture d'un capteur doit retourné une valeur entre 1 et 10, Lors de la lecture, une valeur de 0 ou 11 déclenche une exception qui interrompra les appels en cours, jusqu'au niveau du controleur du système qui trappera l'exception pour re-initialiser convenable le capteur.

Dans ce cas, en pseudo algo, cela peut être ecrit :
...
Valeur = lecture()
si Valeur <1 ou Valeur > 10 alors
raise Hors_limite;
...

Je préfere nettement, la vision déclarative qui sépare nettement les cas d'erreurs ou exceptionnels de l'algo nominale sans pour autant terminer l'application.
Header :
Check Valeur < 1 ou Valeur > 10, sinon exception Hors_limite
Code :
...
Valeur = lecture()
...


2. La propagation et la capture de l'exception reste à définir. Le contexte de remontée ne doit pas créer de nouveaux objets (difficile en cas de memoire pleine...) mais devrait plutot s'appuyer sur un contexte statique réservé à cet usage.

3. Dans une vision volontairement unifiée, les exceptions pourraient apporter à lisaac :
- un mécanisme générique de remontée d'erreur :
- émis par les contrats, pouvant être utilisé en debug mais également en production.
- émis volontairement par le programmeur
- être le support générique de terminaison de bloc, méthode ou programme.



Sur les exceptions ADA (dans le même esprit que cellede PL/1).
La structure de l'exception ADA est a la fois :
- intrégré dans la structure syntaxique (fait partie intégrante du bloc)
- simple d'usage
- Le contexte transmis est statique, une exception levée et trappée doit être traité avant q'une autre puisse être levée. ceci évite les tentation de traitement complexe dans l'exception.....
pour aller plus loin dans ce sens, un commentaire sur le sujet :
http://www.les-ziboux.rasama.org/faq-ada-presentation.html#e(...)