de l'interet de ce que j'avais fait en perl à savoir un systeme de reprise sur erreur au travers d'un mécanisme de gestion d'exception.
Cela permettait d'ecrire des choses du genre :
bla();
blo();
bli();
Et si blo() générait une exception de ce genre, le gestionnaire corrigeait le contexte et comme si de rien était dans blo().
Ce qui allege le code et sa lisibilité ... en prime, l'on pouvait déclarer des gestionnaires permanents ... ce qui evitait les try{} catch() à gogo si le catch faisait toujours la même chose.
J'avais meme parlé dans la doc d'un systeme de code transactionnel avec possibilité de rollback de contexte, mais je n'ai jamais publié le code et il fut perdu lors d'un crash disque avec backup defectueux ( comme quoi publier du code, c'est aussi la garanti d'un backup distribué peu onereux ;) ) ... cela se basait sur une réécriture de Safe.
Cela offrait l'avantage avec le module précedent, de pouvoir rejouer à la volée tout un pavé de code sans avoir à coder de manière descriptive une séquence du genre catch/control/replay_or_fail
Des mécanismes de ce genre permettent de limiter le risque de corruption de données lors du traitement des erreurs ou lors d'une interruption inopinée de service, et reduisent le risque d'introduction d'erreur dans la gestion d'erreur elle meme.
[^] # Re: le mieux est l'ennemi du bien
Posté par Mouns . En réponse au journal Qu'est-ce que bien gérer les erreurs dans ses programmes ?. Évalué à 1.
Cela permettait d'ecrire des choses du genre :
bla();
blo();
bli();
Et si blo() générait une exception de ce genre, le gestionnaire corrigeait le contexte et comme si de rien était dans blo().
Ce qui allege le code et sa lisibilité ... en prime, l'on pouvait déclarer des gestionnaires permanents ... ce qui evitait les try{} catch() à gogo si le catch faisait toujours la même chose.
J'avais meme parlé dans la doc d'un systeme de code transactionnel avec possibilité de rollback de contexte, mais je n'ai jamais publié le code et il fut perdu lors d'un crash disque avec backup defectueux ( comme quoi publier du code, c'est aussi la garanti d'un backup distribué peu onereux ;) ) ... cela se basait sur une réécriture de Safe.
Cela offrait l'avantage avec le module précedent, de pouvoir rejouer à la volée tout un pavé de code sans avoir à coder de manière descriptive une séquence du genre catch/control/replay_or_fail
Des mécanismes de ce genre permettent de limiter le risque de corruption de données lors du traitement des erreurs ou lors d'une interruption inopinée de service, et reduisent le risque d'introduction d'erreur dans la gestion d'erreur elle meme.