Une exception est générée quand une situation anormale entrave le déroulement nominal d’une tâche. Elle peut être générée automatiquement pour signaler une erreur d’exécution (débordement d’indice de tableau, division par zéro, …), ou être soulevée explicitement par une action (RaiseException) pour signaler une situation problématique qui n’est pas prise en charge par la séquence de traitement normale. Graphiquement, on peut représenter le fait qu’une activité peut soulever une exception comme un pin de sortie orné d’un petit triangle et en précisant le type de l’exception à proximité du pin de sortie (cf. figure 6.12).
Un gestionnaire d’exception est une activité possédant un pin d’entrée du type de l’exception qu’il gère et lié à l’activité qu’il protège par un arc en zigzag ou un arc classique orné d’une petite flèche en zigzag. Le gestionnaire d’exception doit avoir les mêmes pins de sortie que le bloc qu’il protège (cf. figure 6.13).
Les exceptions sont des classeurs et, à ce titre, peuvent posséder des caractéristiques comme des attributs ou des opérations. Il est également possible d’utiliser la relation d’héritage sur les exceptions. Un gestionnaire d’exception spécifie toujours le type des exceptions qu’il peut traiter, toute exception dérivant de ce type est donc également prise en charge.
Lorsqu’une exception survient, l’exécution de l’activité en cours est abandonnée sans générer de valeur de sortie. Le mécanisme d’exécution recherche alors un gestionnaire d’exception susceptible de traiter l’exception levée ou une de ses classes parentes. Si l’activité qui a levé l’exception n’est pas protégée de cette exception, l’exception est propagée à l’activité englobante. L’exécution de cette dernière est abandonnée, ses valeurs de sortie ne sont pas générées et un gestionnaire d’exception est recherché à son niveau. Ce mécanisme de propagation se poursuit jusqu’à ce qu’un gestionnaire adapté soit trouvé. Si l’exception se propage jusqu’au sommet d’une activité (i.e. il n’y a plus d’activité englobante), trois cas de figure se présentent. Si l’activité a été invoquée de manière asynchrone, aucun effet ne se produit et la gestion de l’exception est terminée. Si l’activité a été invoquée de manière synchrone, l’exception est propagée au mécanisme d’exécution de l’appelant. Si l’exception s’est propagée à la racine du système, le modèle est considéré comme incomplet ou mal formé. Dans la plupart des langages orientés objet, une exception qui se propage jusqu’à la racine du programme implique son arrêt. Quand un gestionnaire d’exception adapté a été trouvé et que son exécution se termine, l’exécution se poursuit comme si l’activité protégée s’était terminée normalement, les valeurs de sortie fournies par le gestionnaire remplaçant celle que l’activité protégée aurait dû produire.
