[Topic tuto] Les exceptions

Les exceptions [Topic tuto] - Java - Programmation

Marsh Posté le 10-06-2005 à 12:00:02    

Ceci est un premier jet....c'est donc très perfectible.
A noter, on peut trouver des conneries aussi :p
 
PLAN :  
I - Documentation
II - Une exception c'est quoi ?
III - A quoi ca sert ?
IV - Comment traiter une exception ?
V - Comment les utiliser ?
VI - Comment lire un stacktrace ?
VII - Les exceptions classiques ?
 
Convention :  
les liens hypertextes sont formattés comme ceci
 
I - Documentation
Le tutorial de Sun propose une section très complète sur les exceptions
Java Tutorial - Essentials concepts - Exceptions (en anglais)
 
II - Une exception c'est quoi ?
Simplement, une exception est un méchanisme pour faire "remonter" les problèmes qui surviennent dans un programme.
Dans une application, 2 types de problemes peuvent survenir :  
- les problèmes graves, qui rendent l'environnement Java instable : ce sont des problèmes irrécupérables
- les problèmes mineurs, qui n'affectent pas l'environnement. Ce sont des problemes raisonnablement prédictibles, qui si on code correctement, NE DOIVENT PAS entrainer l'arret du programme
 
Avant de donner un exemple, je dois encore préciser que les exceptions sont utilisables par le programmeur pour notifier les erreurs, et que c'est un méchanisme très puissant et très propre de programmation.
 
Une exception est un objet java, qui encapsule :  
- le stacktrace, qui est la liste des dernières méthodes appellées avant que l'exception se produise. C'est en général ce truc rouge qui s'affiche dans la console quand une erreur arrive.
Exemple :  

Code :
  1. Error while parsing
  2. java.text.ParseException: Format.parseObject(String) failed
  3. at java.text.Format.parseObject(Unknown Source)
  4. at com.jubijub.ClasseDeTest.main(ClasseDeTest.java:33)


J'expliquerai plus tard comment lire un stacktrace.
- éventuellement, un objet String contenant un message d'erreur
 
III - A quoi ca sert ?
Prenons un exemple :
Une partie de votre programme doit lire un fichier. Il est parfaitement possible qu'un fichier n'existe pas ou plus, ou qu'il soit illisible, ou verrouillé, pour X raisons. Un programme de ce type doit donc toujours savoir quoi faire si le fichier n'est pas lisible. C'est une erreur raisonnablement prévisible, et il n'y a pas de raison qu'elle entraine l'arret de l'application. De plus, le problème est relativement cloisonné, et n'affecte pas le reste de l'application. Par exemple il vaut mieux, si l'évènement arrive, proposer de chercher un autre fichier.
Les exceptions permettent :  
1) de canaliser les erreurs
2) de déterminer quelle partie de l'application doit traiter l'erreur, et donc comment la traiter
 
 
IV - Comment traiter une exception ?
Je développerai ce point plus tard, mais pour le moment, il faut juste savoir qu'une méthode toto() peut être déclarée comme "jetant une exception", ce qui veut dire qu'elle est susceptible de générer une exception.
 
A partir de là, toute méthode appellant toto() a le choix entre :  
- prendre en charge l'exception
- la "propager" au niveau supérieur, c'est à dire se contenter de la relancer (concept de la patate chaude)
 
Exemple : la méthode baba() appelle la méthode bibi() qui appelle la méthode bobo() qui jette une exception.
- bibi peut catcher l'exception de bobo, ou la relancer
- ce qu'on doit faire dans baba dépend de bibi : si bibi a catché l'exception, baba n'a rien à faire. Sinon bibi a propagé, baba doit catcher l'exception. Si baba relance l'exception, ce sera aux méthode appelant baba() de catcher l'exception.
Si personne ne catche une exception, et qu'elle est propagée tout le temps, elle va sauter à la tete de l'utilisateur, ce qui n'est évidement pas propre.
 
En imagé, une exception c'est comme une petite bombe : soit on la désamorce ("on la catche" ), soit on la refile au voisin (on la "propage" ). Si personne la désamorce, elle pète à la gueule de l'utilisateur.
==> il faut donc toujours catcher une exception à un moment ou à un autre
 
Catcher une exception :  
Prenons l'exemple de bibi() qui appelle bobo() qui jette une exception
 

Code :
  1. public void bibi() {
  2.     try {   // début de la zone où peut se produire l'exception
  3.         ObjetBidon bidon = bobo();
  4.     } catch (BoboException be) { // fin de la zone, début de la zone catch, qui indique quoi faire si exception
  5.         System.out.println("Insérer ici un message informatif" );
  6. be.printStackTrace(); //utile en débug : permet d'afficher la trace
  7.     } // fin de la zone catch
  8. }


 
Il y a plusieurs règles à observer :  

  • ne *** JAMAIS *** faire un catch & bury :  

Le catch & bury c'est ça :  

Code :
  1. try {
  2.  bobo();
  3. } catch (Exception e) {
  4.  // ne rien faire
  5. }


Il est très très très très rare d'avoir à faire ça pour une raison valable...traitez toujours vos exception : logs, remonté du message, procédure pour réinitialiser votre modèle, etc...

  • Essayez de séparer vos exceptions : en effet, une méthode peut lancer plusieurs exceptions, et a fortiori un bloc de code. Essayez de ne pas catcher exception d'un bloc (catch Exception e) mais de catcher chaque exception séparément. Ca améliore la lisibilité du code, ca vous permet de faire des traitements différenciés en fonction de l'erreur. Là c'est à vous de voir, mais c'est plus propre.
  • Pour un fini plus propre de l'application, débrouillez vous catcher toutes vos exceptions...


V - Comment les utiliser ?
Utiliser le méchanisme des exception est certes un peu contraignant (il faut décider où "catcher" l'exception, gérer un finally eventuel, etc...) mais en contrepartie, c'est un méchanisme très souple est très propre pour gérer la remontée d'un problème.
 
Prenons un exemple
Vous construisez une application de gestion de timbres. Chaque timbre dispose d'une cote, que vous souhaitez renseigner.
Vous proposez un écran de saisie d'un nouveau timbre. Vous DEVEZ controler que les données saisies sont correctes. Par exemple, une cote étant un prix, elle ne peut être négative.
Dans votre modèle, vous avez un objet Timbre, avec un attribut cote de type double, et un setCote(double cote) et getCote();
Conceptuellement, votre modèle doit garantir son intégrité, c'est à dire que Timbre doit garantir que les informations qu'on lui fournit sont cohérentes.
 
On peut soit utiliser une Exception existante, soit créer la sienne propre.
 
par exemple, la méthode setCote(double cote) pourrait ressembler à ceci :  
Imaginons qu'on utilise une exception customizée appellée InvalidPriceException

Code :
  1. public void setCote(double cote) throws InvalidPriceException {
  2. if (cote < 0) {
  3. throw new InvalidPriceException("La cote spécifiée ne peut être nulle" );
  4. } else {
  5. this.cote = cote;
  6. }


Le message d'erreur permet de préciser l'exception.
 
N'utilisez les exceptions que pour une bonne raison. Parfois un if/else peut remplacer une exception. La limite est floue est sujette à débat. Posez vous la question : est-ce que sémantiquement, c'est une erreur au sens de mon application ?
Parfois vous serez obligé d'utiliser une exception, parce que java vous l'impose (méthode du package Java.IO, parsing, etc...).
 
VI - Comment lire un stacktrace ?
 
Au secours !!!! J'ai une exception et je comprends pas pourquoi.
 
Un stacktrace est composé comme suit :  
- La première ligne donne le type de l'exception, et le message d'erreur lié
- 1 à n lignes représentant la pile d'appel des méthodes : c'est écrit dans l'ordre décroissant : la dernière méthode appellée est écrite en haut, la première en bas de la liste. Si la source est disponible, la ligne affiche également le fichier java et la ligne où figure la méthode concernée. Si vous utilisez un IDE, un clic sur la ligne vous amène généralement au lieu concerné.
- éventuellement, le thread où s'est passé l'exception
 
Prenons le programme suivant (il est débile, mais c'est pour le test)
Note : l'exception ici renvoyée est une fille de RuntimeException, qui a de ce fait n'a pas forcément à etre catché. Pour les RuntimeException, le catch est facultatif. Les NullPointerException font aussi partie de cette famille.

Code :
  1. public class TesTest {
  2. public TesTest() {
  3. }
  4. public void methodeInutile(String param) {
  5.  if (param.length() <1) {
  6.   throw new IllegalArgumentException("Le paramètre a une longueur nulle" );
  7.  }
  8. }
  9. public static void main(String[] args) {
  10.  TesTest test = new TesTest();
  11.  test.methodeInutile("" );
  12. }
  13. }


 
Imaginons le stacktrace suivant :  

Code :
  1. java.lang.IllegalArgumentException: Le paramètre a une longueur nulle
  2. at com.jubijub.TesTest.methodeInutile(TesTest.java:11)
  3. at com.jubijub.TesTest.main(TesTest.java:17)
  4. Exception in thread "main"


 
On voit :  
- que c'est une java.lang.IllegalArgumentException (on peut donc commencer par aller voir la javadoc de l'exception pour comprendre ce qu'elle signifie, ca aide bcp à trouver le contexte)
- la pile contient 2 appels. D'après le source, on voit que le main a été appellé, puis la méthodeInutile .
- le dernier appel étant méthodeInutile(), il y a de fortes chances que la source de l'exception soit là.
 
En examinant son code, on voit qu'effectivement elle est susceptible de lancer une exception. En regardant le code, on voit que si le param est une string vide ("" ), l'exception est lancée.  
 
On peut donc affirmer que la methodeInutile a reçu "" comme paramètre. En obervant l'appel, on se rend compte que c'est la cas (ici c'est hardcodé, mais si c'était dynamique, il faudrait alors trouver pourquoi la String est vide)
 
Un peu plus dur :p

Code :
  1. [10/06/05 09:33:03:781 CEST] 64cf64cf SystemErr     R java.lang.NullPointerException
  2. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at java.lang.Throwable.<init>(Throwable.java)
  3. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at java.lang.Throwable.<init>(Throwable.java)
  4. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at java.lang.NullPointerException.<init>(NullPointerException.java)
  5. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.PouetPouet.command.UpdateUserFromFormCommand.performExecute(UpdateUserFromFormCommand.java:97)
  6. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.PouetPouet.framework.command.LocalTarget.executeCommand(LocalTarget.java:23)
  7. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.PouetPouet.framework.command.TargetableCommandImpl.execute(TargetableCommandImpl.java:40)
  8. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.PouetPouet.j20leanadm.web.action.usersManagement.UpdateUserAction.myExecute(UpdateUserAction.java:59)
  9. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.PouetPouet.j20leanadm.web.action.AbstractAction.performExecute(AbstractAction.java:42)
  10. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.PouetPouet.framework.web.struts.action.VolvoITAction.execute(VolvoITAction.java:41)
  11. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
  12. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
  13. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
  14. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
  15. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
  16. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
  17. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
  18. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
  19. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
  20. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
  21. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
  22. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
  23. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
  24. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java)
  25. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java)
  26. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java)
  27. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:79)
  28. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:201)
  29. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
  30. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.invoke(CacheableInvocationContext.java:114)
  31. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:186)
  32. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
  33. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
  34. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:610)
  35. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.http.HttpConnection.run(HttpConnection.java)
  36. [10/06/05 09:33:03:796 CEST] 64cf64cf SystemErr     R  at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java)


 
Comment s'y retrouver ?
La pile est énorme ici.
Première chose, regarder les packages :  
y'a du java.lang, y'a du com.PouetPouet, y'a du org.apache, et y'a du com.ibm ...on peut espérer que le problème ne vienne pas des outils utilisés, et que ca vient de notre code. On peut déjà restreindre à com.PouetPouet.
 
Il suffit alors de suivre les appels du plus récent au plus ancien. Attention, la lecture est ici obscurcie du fait d'une hiérarchie de classe (y'a le type Struts + 3 surtypes en dessous)...
 
VII - Les exceptions classiques ?
La NullPointerException (appellée "NPE" )
Cette exception, très fréquente, indique que l'on a tenté d'accéder à une méthode ou un champs d'un objet ayant une valeur nulle.
 
Par exemple :  

Code :
  1. User user = null;
  2. System.out.println(user.getName());


user vaut null. On essaye d'appeller une méthode sur un objet à null. Ca va générer une nullPointerException.
 
Comment la résoudre :  
Imaginons :  

Code :
  1. System.out.println(user.getProfile().getFamilly().getSuperFamilly().getId());


Si cette ligne renvoit une NPE, ca peut etre :  
- parce que user est null
- parce que le profile est null
- parce que la profile family est nulle
- parce que la superFamily est nulle
 
Il vous faudra donc tester patiemment pour trouver lequel est nul.
 
 
 


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 10-06-2005 à 12:00:02   

Reply

Marsh Posté le 10-06-2005 à 12:16:06    

Jubijub a écrit :


Code :
  1. public void bibi() {
  2.     try {   // début de la zone où peut se produire l'exception
  3.         ObjetBidon bidon = bobo();
  4.     } catch (BoboException be) { // fin de la zone, début de la zone catch, qui indique quoi faire si exception
  5.         System.out.println("Insérer ici un message informatif" );
  6. be.printStackTrace(); //utile en débug : permet d'afficher la trace
  7.     } // fin de la zone catch
  8. }


....

Code :
  1. try {
  2.  bobo();
  3. } catch (Exception e) {
  4.  // ne rien faire
  5. }



c'est quoi la différence ?

Reply

Marsh Posté le 10-06-2005 à 13:44:58    

ben dans le premier je fais un truc : je fais un pseudo log...mais t'a raison je pourrais mettre un truc plus complet...mais je vois pas quoi vu la pauvreté de l'exemple


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 10-06-2005 à 13:58:04    

tu wrappes l'exception dans une exception de layer plus haut :o
 
et tu expliques quand on arrête la chaîne.

Reply

Marsh Posté le 10-06-2005 à 15:09:10    

nraynaud a écrit :

tu wrappes l'exception dans une exception de layer plus haut :o
 
et tu expliques quand on arrête la chaîne.


je pense qu'il t'en voudrais pas si tu participais à la rédaction de son topic ... :)


---------------
ma vie, mon oeuvre - HomePlayer
Reply

Marsh Posté le 10-06-2005 à 15:14:00    

ouais, c'est vrai ca, on wrappe quand et comment ? paske je trouve on passe la moitié du temps a wrapper les exceptions
 

Reply

Marsh Posté le 10-06-2005 à 15:20:27    

benou a écrit :

je pense qu'il t'en voudrais pas si tu participais à la rédaction de son topic ... :)


je suis développeur .net moi mossieur :o

Reply

Marsh Posté le 10-06-2005 à 15:40:49    

la chance !!  ;)


Message édité par phnatomass le 10-06-2005 à 15:41:18
Reply

Marsh Posté le 10-06-2005 à 15:42:19    

nraynaud a écrit :

je suis développeur .net moi mossieur :o


 
dit il alors qu'il sait meme pas faire un .ToString() [:pingouino]

Reply

Marsh Posté le 10-06-2005 à 15:45:26    

chrisbk a écrit :

dit il alors qu'il sait meme pas faire un .ToString() [:pingouino]


oué, pas trop l'habitude du dispatching statique [:pingouino]

Reply

Marsh Posté le 10-06-2005 à 15:45:26   

Reply

Marsh Posté le 10-06-2005 à 15:46:41    

regardé comment il tente de noyer le poisson sous du voca [:pingouino] (d'autant plus que son histoire de dispatching il l'a decouverte y'a 2min alors qu'il planche sur le sujet depuis ce matin [:pingouino])
 
t'es rien qu'un gros mauvais [:pingouino]

Reply

Marsh Posté le 10-06-2005 à 15:47:43    

chrisbk a écrit :

il planche sur le sujet depuis ce matin [:pingouino]


[:pingouino] ça fait longtemps que le sujet était parti à la poubelle !

Reply

Marsh Posté le 10-06-2005 à 15:48:50    

stoi la poubelle [:pingouino]

Reply

Marsh Posté le 10-06-2005 à 16:19:56    

[:androids974]

Reply

Marsh Posté le 10-06-2005 à 16:33:10    

t'as oublié de causer des exceptions checked et unchecked


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 10-06-2005 à 16:47:50    

sauf celle qui derive de runtime, noob


---------------
NP: HTTP Error 764 Stupid coder found
Reply

Marsh Posté le 10-06-2005 à 16:51:57    

sté koi la connerie ? [:petrus75]
edit: tiens, on voit plus les posts effacés ? :heink:


Message édité par Harkonnen le 10-06-2005 à 16:53:45

---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 10-06-2005 à 16:52:34    

bin lis le topic, andouillette de veau


---------------
NP: HTTP Error 764 Stupid coder found
Reply

Marsh Posté le 10-06-2005 à 16:54:09    

han j'y crois pas [:mlc] comment il renie sa nullité :o


---------------
NP: HTTP Error 764 Stupid coder found
Reply

Marsh Posté le 10-06-2005 à 16:54:37    

tu vaux guere plus qu'un nraynaud des mauvais jours :o


---------------
NP: HTTP Error 764 Stupid coder found
Reply

Marsh Posté le 10-06-2005 à 16:56:16    

chrisbk a écrit :

han j'y crois pas [:mlc] comment il renie sa nullité :o


si c'était le cas, j'aurais pas avoué ma betise avant l'effacement :o
bref

Reply

Marsh Posté le 10-06-2005 à 16:57:39    

chrisbk a écrit :

bin lis le topic, andouillette de veau


ben je lis, résidu de fausse couche :o
 

lorill a écrit :

j'ai effacé pour pas induire les lecteurs futurs en erreur :o


dis plutot pour pas qu'on voie que l'auteur d'un logiciel apprécié et reconnu est en fait une bleusaille absolue :o
(t'as effacé normalement ? parce que je devrais voir quand meme ton post :heink:)


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 10-06-2005 à 16:58:47    

bon, toujours est il que tchoupi a oublié de parler des unchecked exceptions :o


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 10-06-2005 à 16:59:05    

Harkonnen a écrit :

ben je lis, résidu de fausse couche :o


 
oué bin desolé j'avais pas vu que la manoeuvre d'effacement que lorillmicrocouilles avait fait :o ce paltoquet clamait qu'il n'y avait que des exceptions checked en java :o trop grave la tehon sa race :o


---------------
NP: HTTP Error 764 Stupid coder found
Reply

Marsh Posté le 10-06-2005 à 17:00:35    

[:akt]

Reply

Marsh Posté le 10-06-2005 à 17:01:43    

chrisbk a écrit :

ce paltoquet clamait qu'il n'y avait que des exceptions checked en java :o


hannn ptain, c'tespèce de n00b [:mlc]
c'est sur ce topic qu'il aurait du aller :o


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 10-06-2005 à 17:02:44    

:fuck:

Reply

Marsh Posté le 10-06-2005 à 17:02:54    

voir meme cui la  [:mlc][:mlc]
http://forum.hardware.fr/forum2.ph [...] ash_post=0
 


---------------
NP: HTTP Error 764 Stupid coder found
Reply

Marsh Posté le 10-06-2005 à 17:06:08    


non mais clair ptain [:mlc]
faudrait même carrément qu'il change de forum, et qu'il aille sur celui ci [:mlc] [:mlc]


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 10-06-2005 à 17:07:08    

vous n'êtes pas gentil

Reply

Marsh Posté le 10-06-2005 à 17:07:52    

chrisbk a écrit :

tu vaux guere plus qu'un nraynaud des mauvais jours :o


mais lâche moi, je suis malade, submergé d'informations et dans un environnement hostile bordel [:sisicaivrai]

Reply

Marsh Posté le 10-06-2005 à 17:12:14    

bon nraynal, avoue, l'auteur de Lucane, c'est toi hein ? nan parce que tu me feras pas croire que c'est l'autre bleusaille-qui-sort-des-conneries-plus-grosses-que-lui qui a pondu ce soft :o


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 10-06-2005 à 17:22:45    

lorill est un mec qui fini les choses lui, pas comme moi :o

Reply

Marsh Posté le 10-06-2005 à 20:21:06    

j'en avais parlé mais g viré le passage, pour pas rallonger encore...c pas hyper essentiel au début...


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 10-06-2005 à 22:05:38    

nraynaud a écrit :

lorill est un mec qui fini les choses lui


[:rofl]
 
ca se saurait...  

Reply

Marsh Posté le 10-06-2005 à 23:01:56    

lorill a écrit :

[:rofl]
 
ca se saurait...


pourtant ta copine m'a certifié que tu était plutôt du genre à finir rapidement et complètement :o


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 10-06-2005 à 23:08:27    

c'est quand que tu passes a strasbourg acheter un costard pour uriel déja ?

Reply

Marsh Posté le 10-06-2005 à 23:35:50    

bon, les frontières de propagation des exceptions, ce sont en général les systèmes de passage de messages.
 
Une petite explication :
 
une exception remonte la pile du thread où elle s'est déclenchée, typiquement en se faisant wrapper au fil de l'eau de manière de plus en plus compréhensible de l'utilisateur.
 
Sauf que dans la vraie vie, l'utilsateur n'est pas un thread qui exécute des fonctions, et qui régulièrement se mangerait une exception dans le menton qui lui pêterait 2 dents. En général, le thread qui lance l'exception n'est pas celui qui a demandé l'action de plus haut niveau (on a souvent : un thread délégué au réseau, un thread délégué à l'UI, un thread délégué à du calcul asychrone etc.), on demande à d'autres threads de faire un truc pendant qu'on fait autre chose et on surveille une file de messages.
On peut donc souvent voir l'application comme une collection de threads qui s'envoient des messages (2-3 dans une application cliente typique, des dizaines quand on attaque un serveur d'application J2EE). Les applications en ligne de commande non-interactives sont dans une catégorie à part.  
 
Or donc, dans ce modèle, on ne peut pas se permettre de casser la boucle principale (prendre un message/le traiter etc.) parce qu'elle ne sert pas qu'à l'opération foireuse, mais aussi à des dizaines de trucs innocents, donc pas question de laisser filer les exceptions jusqu'en haut de la pile, il faut les arrêter dans la boucle, passer un message représentant une erreur aux voisins que ça intéresse, et reprendre le cycle "prendre un message/le traiter".
 
Il existe aussi un autre grand paradigme : les threads jetables. Par exemple, le thread qui va faire une compression ZIP pendant que qu'une barre de progression est affichée (en réalité le thread graphique est beaucoup plus utile que ça dans cette situation : il va aussi faire de la peinture lors des ocultations de fenêtre, traiter les évènements des boutons etc.). Ce thread est destiné à mourir en fin de traitement ; s'il survient une exception, comme les autres, il va simplement passer un message au thread d'affichage et mourir.
 
Celui qui reçoit le message d'erreur, en général ne relancera pas l'exception (souvent, le message signifiant l'erreur d'ailleur ne la contiendra pas) mais aura un traitement "réel" de l'erreur, qui sera intégré au niveau business. Un serveur web lancera probablement un 500 et un paté dans les logs, chrisbk lancera un sujet sur les églises en cat Ada, une application sur le bureau ouvrira probablement une fenêtre d'erreur, un serveur d'application rollbackera avant de faire sa galette dans les logs et d'envoyer chier la file des messages JMS etc.
Un exception notable à ce principe est la délégation d'exécution, par exemple en RMI, on délègue l'appel d'une méthode à un autre système, mais on reprend l'exception distante éventuelle à son propre compte. De même pour les exception issues d'un appel par introspection ou un wrapping d'un autre langage par RMI.
 
 
voilou sur les frontières d'exécution.


Message édité par nraynaud le 11-06-2005 à 00:05:25

---------------
trainoo.com, c'est fini
Reply

Marsh Posté le 10-06-2005 à 23:37:57    

t'as oublié le costard :o


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Marsh Posté le 10-06-2005 à 23:40:14    

lorill a écrit :

c'est quand que tu passes a strasbourg acheter un costard pour uriel déja ?


arrêt de te frotter à ma jambe comme ça !
 
 
 
Et merde ! trop tard, il a salopé mon futal !


---------------
trainoo.com, c'est fini
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed