Bon, je recherche pas de code, ni quoi que ce soit, juste des idées. Alors je vais recapituler ce que je connais, et si vous avez des trucs a ajouter ca serait sympa de le faire.
 
- méthode primitive :  
une fonction renvoie une valeur, et on se base sur celle ci pour savoir si une erreur a eu lieu.
 
- methode un peu plus descriptive :
comme la primitive, mais un code d'erreur est renseigné dans une variable globale (errno en C)
 
- goto :
basic style, on error goto truc, et on a aussi un numero d'erreur
 
- exceptions simples (goto amélioré)
cas de PL/SQL, les exceptions sont en fait des labels, vers lesquels on saute en cas d'erreur.
 
- exceptions
cas de la plupart des langages modèrnes, une fonction renvoi un objet un peu particulier qui contient un descriptif de l'erreur.
 
Alors en fait, ma question, c'est est-ce qu'il y a encore plus évolué que les exceptions ? Et si oui, avez vous des docs la dessus ?

 
dans certain projet il est interessant de connaitre la source du plantage, la fonction ou le script qui appelle la fonction qui plante.
 

ben dans les systèmes avec exception, c'est ce que j'appelle le descriptif de l'erreur. Y'a moyen d'avoir ces infos avec d'autres systèmes ?

Oui, avec des "assertion"
 
Avec ca tu as la ligne d'erreur dans ton source directement, pratique quand tu distribues un soft.  
 

Voila ce que ca donne en pascal
 
 

 
Merci, mais c'est plus de la prévention en fait.
En gros, ca teste, et si c'est faux une exception est lancée. Rien de bien extraordinaire, donc.

Ah si, tu sais dans quel source et à quelle ligne tu as un problème, pas besoin de te casser les burnes pour savoir ou tu as balancé l'exception.

Ben ca java le fait aussi, python aussi, ruby aussi, et sans doute pas mal d'autre. En fait doit y avoir que C++ qui le fait pas (et j'en suis même pas sur)

Ouai, enfin ici tu as une distinction entre excpetion et assertion.  Tu veux qu'on parle mécanisme de gestion des erreurs, donc on parle  

zion a écrit a écrit : Ouai, enfin ici tu as une distinction entre excpetion et assertion.  Tu veux qu'on parle mécanisme de gestion des erreurs, donc on parle

te fâche pas, va
 
n'empeche que assert(toto == tata) c'est la même chose que if(toto != tata) throw new AssertionException("message" ), non ?
 
donc d'un point de vue implémentation c'est juste une instruction supplémentaire, j'ai bon ?

 
Benh non, une exception tu sais pas ou elle a été balancée (oui en java, gnagnagna), mais sur le principe, si il te dit la ligne exacte ou a été balancée l'exception, je m'en fous, moi je veux savoir ou elle a été causée plutot (genre un double free, je veux que ca plante la ou je tape le free, pas dans le free).
 
Et ici, l'assertion ca te permet de prévenir et le compilo gère pour toi la ligne et tout le toutim.  
 
Mais a part les exceptions/assertions, je vois rien de mieux  

ok, donc en fait ca permet de pallier au manque d'infos disponibles pour les langages compilés si je comprends bien.  
Pour ton info, dans le cas des langages que j'ai cité, tu n'as pas que la ligne où a été créée l'exception, mais tout le chemin qu'elle a parcouru.

Euh, ca, tu sais aussi l'avoir ici, le groupe pour lequel je bosse quand j'ai un peu de temps libre a fait un compo pour ca... Tu le balances sur ton application, il récupère les appels sur le stack, les valeurs des registres, etc, etc, et il propose un joli dialogue pour envoyer un mail.
 
Je devrais l'utiliser tiens  

Les assertion ca marche qu'en debug il me semble ... pas sur la version du client.
Sinon y'a le core dump. Le client te l'envoit, tu lances ton debuggueur et te voila sur l'erreur.
Y'a les signaux sous Unix, le SEH sous Windows, ...
Y'a les watchdog aussi. C'est utilisé dans les systèmes embarqués ou personne n'est là pour faire un reset. Si une boucle infinie bloque trop longtemps fiout on reset !
Justement, j'ai récemment eu mon premier ecran bleu WinXP ... mon ordi a freezé et puis au bout d'une dizaines de secondes, ecran bleu, le watchdog me dit ou a eu lieu l'erreur. Pas mal !
http://www.chez.com/regatbar/bsod%20xp/BSOD_XP.htm

zion a écrit a écrit : et il propose un joli dialogue pour envoyer un mail.   Je devrais l'utiliser tiens

 
c'est quel compo je devrais l'utiliser aussi

antp a écrit a écrit :     c'est quel compo je devrais l'utiliser aussi

 
Je sais plus, c'est dans la JCL. JclDebug je dirais    
 
Sinon si, les assertions ca marche sur la version finale de l'utilisateur aussi, bien qu'on préfère les désactiver vu que le mec il est pas censé avoir ce genre d'informations    
 
Sinon y a aussi le remote debug avec Delphi, j'ai pas encore eu le temps de tester mais ca a l'air sympa...

lorill> Ta description des différents mécanismes d'erreur me semble incomplète, car le mécanisme de récupération sur erreur est aussi important que le mécanisme de déclenchement de l'erreur. C'est même le mécanisme de récupération qui différencie ces mécanismes et rend l'un meilleur que l'autre.
 
Ainsi, normalement, une assertion est irrécupérable : le programme s'arrête si elle n'est pas vérifiée, point (Java est un mauvais exemple en matière d'assertion, puisqu'il l'assimile à une exception).
 
Par ailleurs, le ON ERROR GOTO ou ON ERROR GOSUB du BASIC, suivi d'un RESUME pour revenir au mode de fonctionnement normal, est très différent du mécanisme des exceptions, puisque l'instruction RESUME va tenter de ré-exécuter l'instruction qui a déclenché l'erreur. Alors que pour les exceptions, on quitte le code en cours pour aller directement à l'appelant (ou le bloc traite-exception encapsulant).
 
Pour finir et pour répondre à la dernière question de ton premier post, à ma connaissance, il n'y a pas actuellement de mécanisme de récupération sur erreur plus souple (et ausii simple) que celui qu'offre les exceptions.

Merci, c'est vrai que j'ai complétement occulté les différences en ce qui concerne le retour au code après erreur.