Il s'agit encore d'un problème de lisibilité et non de défense d'ADA.
En ADA chaque bloc possède implicitement un section exception qui fait partie de la structure syntaxique. Il est donc aisé de mettre en oeuvre une exception; la programmation par exception est alors réalisable pour exprimer clairement un algorithme et ses conditions d'arrêts qui peuvent être analysés à differents niveaux y compris au niveau le plus haut pour re-initialisé un système par exemple.
Begin
...
Exception:
excep1 => traitement1()
End
Les langages plus récents ont cantonnés les exceptions à de la gestion d'erreurs tout en voulant adjoindre une mécanique de remontée d'informations. Ceci est louable mais alourdi considérablement la syntaxe au point de ne pouvoir l'utiliser pour autre chose de la gestion d'erreurs. Il suffit d'imbriquer 2 ou 3 blocs d'exception en Java pour se rendre compte du probleme.
Dans un système temps réel, les conditions d'arrêt sont multiples et souvent provenant de cause hors logiciel, il est plus simple de lâcher une exception et de la trapper au niveau adéquat pour reprendre le traitement sans devoir gérer la pile d'erreurs en cascade en retour de chaque fonction.
[^] # Re: Les trous de lIsaac
Posté par gloups . En réponse au journal Des langages de haut niveau. Évalué à 2.
En ADA chaque bloc possède implicitement un section exception qui fait partie de la structure syntaxique. Il est donc aisé de mettre en oeuvre une exception; la programmation par exception est alors réalisable pour exprimer clairement un algorithme et ses conditions d'arrêts qui peuvent être analysés à differents niveaux y compris au niveau le plus haut pour re-initialisé un système par exemple.
Begin
...
Exception:
excep1 => traitement1()
End
Les langages plus récents ont cantonnés les exceptions à de la gestion d'erreurs tout en voulant adjoindre une mécanique de remontée d'informations. Ceci est louable mais alourdi considérablement la syntaxe au point de ne pouvoir l'utiliser pour autre chose de la gestion d'erreurs. Il suffit d'imbriquer 2 ou 3 blocs d'exception en Java pour se rendre compte du probleme.
Dans un système temps réel, les conditions d'arrêt sont multiples et souvent provenant de cause hors logiciel, il est plus simple de lâcher une exception et de la trapper au niveau adéquat pour reprendre le traitement sans devoir gérer la pile d'erreurs en cascade en retour de chaque fonction.