Exceptions et Asynchronisme

1
Exceptions et Asynchronisme

• Guillaume Chazarain

Filière SAR/Master STIC Spécialité RSD 2005
Maître de stage Denis Caromel
Projet OASIS (Projet commun INRIA, CNRS-I3S, UNSA)
2
Exceptions
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Séparation du code normal de celui de gestion
  derreur
• Association syntaxique des blocs

try // Code normal // lappel
signale une // exception appel() //
Code ignoré appel2() catch (UneException
ue) // Gestion derreur traite(ue)
finally // Code exécuté dans // tous
les cas

• Lexception est un objet standard
• Pile de masques dexceptions
• Remontée de la pile dappels

3
Asynchronisme
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Fourni par ProActive librairie Java
• Objets actifs appels asynchrones
• Appel de méthode à la RPC
• Poursuite de lexécution pendant le traitement de
  lappel
• Retour dun objet futur
• Attente par nécessité à lutilisation du futur

res1 ao1.foo1(param1) res2
ao2.foo2(param2) res res1.foo(res2)
4
Incompatibilités
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Exceptions liées au synchronisme
• Basées sur la remontée de pile
• Avec l'asynchronisme l'état de la pile n'est plus
  garanti

// foo1 et foo2 peuvent // signaler des
exceptions try res1 ao1.foo1(param1)
res2 ao2.foo2(param2) catch (UneException e)
// Gestion derreur res res1.foo(res2)

• Solution basique traiter en synchrone les
  appels susceptibles de signaler des exceptions
• Notre contribution passage à lasynchronisme

5
Approches Principales
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Fonctions et objets de traitement
• Une fonction donnée est appelée lorsquune
  exception est signalée
• JR, NFE, Kava, ARMI
• Exceptions dans le futur
• Signalisation de lexception lors de laccès au
  futur
• Peu dimplémentations
• Mandala/RAMI, Java 1.5, ARMI

6
Analyse
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion
Approche Avantages Inconvénients
Fonctions et objets de traitement Facile Répandu Comportements génériques Mauvaise capture du contexte, Remontée de la pile impossible, Poursuite de lexécution limitée
Exception dans le futur Réutilise un véritable mécanisme de gestion d'erreurs Complexité Exception signalée de manière imprévisible
7
Notre Solution Les Barrières
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Exception dans le futur avec barrière à la sortie
  des blocs
• Lexception est signalée lors de laccès au futur
• Avant de sortir dun bloc on attend le retour des
  appels associés au bloc types dexception
  compatibles
• Garantie que l'exception n'est pas signalée trop
  tard

8
Exemple
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• tryWithCatch
• Empile le masque dexceptions

// foo1 et foo2 peuvent // signaler des
exceptions tryWithCatch(UneException.class) try
res1 ao1.foo1(param1) res2
ao2.foo2(param2) endTryWithCatch() catch
(UneException e) // Gestion derreur
finally removeTryWithCatch() res
res1.foo(res2)

• endTryWithCatch
• Attend le retour des appels
• Dépile le masque dexceptions
• removeTryWithCatch
• Corrige la pile

9
Barrière à l'entrée
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Blocs imbriqués

class ParentException extends Exception class
ChildException extends ParentException try
A a ro.foo() // throws ChildException /
Barrière ici / try a.bar() catch
(ParentException pe) // Traitement
de ParentException catch (ChildException
ce) // Traitement de ChildException

• L'exception serait traitée dans le bloc interne
  plutôt que le bloc externe

10
Asynchronisme Conséquence
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Appels consécutifs illégaux
• Signaler lexception le plus tôt possible ?
• Non comportements imprévisibles
• Utilisation de lattente par nécessité

// foo1 et foo2 peuvent // signaler des
exceptions try res1 ao1.foo1(param1)
res2 ao2.foo2(param2) catch (UneException e)
// Gestion derreur res res1.foo(res2)

• Exceptions consécutives
• En synchrone uniquement la première
• On ne garde que la première

11
Implémentations
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Pile de masques d'exceptions
• Celle de Java est inaccessible
• Nécessiter d'en recréer une
• Annotations simples des try/catch
• Modificateur de code source
• Parse les blocs
• Annotations automatiques

12
Désynchronisation des piles
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion
// foo1 et foo2 peuvent // signaler des
exceptions tryWithCatch(UneException.class) try
res1 ao1.foo1(param1) res2
ao2.foo2(param2) endTryWithCatch() catch
(UneException e) // Gestion derreur
finally removeTryWithCatch()
Ex.class
Ex.class
Pile de Java
Pile émulée

• Aucune information quand une exception est
  signalée
• La pile émulée est corrompue
• Réparation dans le finally

13
Application Calcul de ?
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Calcul arithmétique sur les fractions
• Chaque appel peut signaler une condition
  doverflow
• Asynchronisme limité par les exceptions
• Distribution du calcul de la série
• Découpage régulier de la somme sur 4 machines
• 3 fois moins de temps avec notre contribution

ProActive normal ProActive contribution
60 secondes 20 secondes
14
Conclusions
Introduction - Problématiques - État de l'Art -
Notre approche - Conclusion

• Mécanismes existants insuffisants
• Passage de synchrone à asynchrone
• Mise en œuvre complexe
• Publication Robust Exception Handling in an
  Asynchronous Environment
• ECOOP2005 - Workshop on Exception Handling in
  Object Oriented Systems