“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 95 — #105
i
i
i
i
i
i
i
i
2.7 Les exceptions
95
variables booléennes et des instructions conditionnelles. Cela fait des programmes
plus encombrants, surtout parce que le code supplémentaire doit être ajouté partout où
une erreur est possible. On peut montrer formellement que la seule manière de garder
la simplicité des programmes est d’étendre le modèle [51, 54].
Nous proposons une extension simple au modèle qui satisfait ces conditions. Nous
ajoutons deux instructions : l’instruction try et l’instruction raise. L’instruction
try crée un contexte de capture d’exceptions avec un traitement d’exceptions. L’instruction raise lève une exception : elle fait un saut jusqu’à la frontière du contexte
de capture d’exceptions le plus imbriqué et elle appelle ensuite le traitement d’exceptions de ce contexte. Des instructions try imbriquées créent des contextes imbriqués.
L’exécution de try s catch x then s 1 end est équivalente à l’exécution de
s, si s ne lève pas une exception. Par contre, si s lève une exception, par l’exécution d’une instruction raise, alors l’exécution (en cours) de s est annulée. Toutes
les informations associées à s sont enlevées de la pile sémantique. Le contrôle est
transféré à s 1 et une référence à l’exception est donnée à x.
Toute valeur partielle peut être une exception. Le mécanisme de traitement d’exceptions est donc extensible par le programmeur. De nouvelles exceptions peuvent
être définies au besoin par le programme. Le programmeur peut prévoir de nouvelles
situations exceptionnelles. Parce qu’une exception peut être une variable non liée, la
lever et la déterminer peuvent être faits de façon concurrente. En d’autres termes, une
exception peut être levée (et capturée) avant de savoir de quelle exception il s’agit !
C’est tout à fait raisonnable dans un langage avec des variables dataflow : il est possible que nous sachions l’existence d’un problème sans savoir la nature exacte du
problème.
Un exemple
Nous donnons un petit exemple de traitement d’exceptions. Considérez la fonction
suivante, qui évalue des expressions arithmétiques simples et renvoie le résultat :
fun {Eval E}
if {IsNumber E} then E else
case E of plus(X Y) then {Eval X}+{Eval Y}
[]
times(X Y) then {Eval X} * {Eval Y}
else raise illFormedExpr(E) end
end
end
end
Dans cet exemple, nous disons qu’une expression est mal formée si elle n’est pas
reconnue par Eval, c’est-à-dire si elle contient d’autres valeurs que des nombres,
des plus et des times. Essayer l’évaluation d’une expression E qui est mal formée
© Dunod – La photocopie non autorisée est un délit
i
i
i
i
i
i
i
i
2.7 Les exceptions
95
variables booléennes et des instructions conditionnelles. Cela fait des programmes
plus encombrants, surtout parce que le code supplémentaire doit être ajouté partout où
une erreur est possible. On peut montrer formellement que la seule manière de garder
la simplicité des programmes est d’étendre le modèle [51, 54].
Nous proposons une extension simple au modèle qui satisfait ces conditions. Nous
ajoutons deux instructions : l’instruction try et l’instruction raise. L’instruction
try crée un contexte de capture d’exceptions avec un traitement d’exceptions. L’instruction raise lève une exception : elle fait un saut jusqu’à la frontière du contexte
de capture d’exceptions le plus imbriqué et elle appelle ensuite le traitement d’exceptions de ce contexte. Des instructions try imbriquées créent des contextes imbriqués.
L’exécution de try s catch x then s 1 end est équivalente à l’exécution de
s, si s ne lève pas une exception. Par contre, si s lève une exception, par l’exécution d’une instruction raise, alors l’exécution (en cours) de s est annulée. Toutes
les informations associées à s sont enlevées de la pile sémantique. Le contrôle est
transféré à s 1 et une référence à l’exception est donnée à x.
Toute valeur partielle peut être une exception. Le mécanisme de traitement d’exceptions est donc extensible par le programmeur. De nouvelles exceptions peuvent
être définies au besoin par le programme. Le programmeur peut prévoir de nouvelles
situations exceptionnelles. Parce qu’une exception peut être une variable non liée, la
lever et la déterminer peuvent être faits de façon concurrente. En d’autres termes, une
exception peut être levée (et capturée) avant de savoir de quelle exception il s’agit !
C’est tout à fait raisonnable dans un langage avec des variables dataflow : il est possible que nous sachions l’existence d’un problème sans savoir la nature exacte du
problème.
Un exemple
Nous donnons un petit exemple de traitement d’exceptions. Considérez la fonction
suivante, qui évalue des expressions arithmétiques simples et renvoie le résultat :
fun {Eval E}
if {IsNumber E} then E else
case E of plus(X Y) then {Eval X}+{Eval Y}
[]
times(X Y) then {Eval X} * {Eval Y}
else raise illFormedExpr(E) end
end
end
end
Dans cet exemple, nous disons qu’une expression est mal formée si elle n’est pas
reconnue par Eval, c’est-à-dire si elle contient d’autres valeurs que des nombres,
des plus et des times. Essayer l’évaluation d’une expression E qui est mal formée
© Dunod – La photocopie non autorisée est un délit