Gestion des erreurs et affichage de messages à l'utilisateur
2 réponses
david hautbois
Salut
Je bricole un peu en python/GTK.
Et il y a un truc avec lequel je ne suis pas super à l'aise : la
remontée des erreurs à l'utilisateur.
Depuis mon interface, j'appelle une fonction qui appelle un fonction qui
appelle une fonction.
Généralement ça ne dépasse pas 3-4 appels.
Si la fonction en bout de chaine rencontre une erreur, je galère un peu
à faire remonter l'erreur jusqu'à l'utilisateur.
dernièrement j'utilise la méthode :
soit je retourne le tuple (1, resultat) si ça se passe bien
soit je retourne (-1, message d'erreur) en cas d'erreur
Je ne trouve pas çe très élégant.
Je devrait peut être déclencher des exceptions personnalisées....
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bruno Desthuilliers
david hautbois a écrit :
Salut Je bricole un peu en python/GTK. Et il y a un truc avec lequel je ne suis pas super à l'aise : la remontée des erreurs à l'utilisateur.
Depuis mon interface, j'appelle une fonction qui appelle un fonction qui appelle une fonction. Généralement ça ne dépasse pas 3-4 appels. Si la fonction en bout de chaine rencontre une erreur, je galère un peu à faire remonter l'erreur jusqu'à l'utilisateur.
dernièrement j'utilise la méthode : soit je retourne le tuple (1, resultat) si ça se passe bien soit je retourne (-1, message d'erreur) en cas d'erreur
Je ne trouve pas çe très élégant.
Effectivement. D'autant que Python est un peu plus évolué que ça - on a les exceptions pour gérer ce genre de problème.
Je devrait peut être déclencher des exceptions personnalisées....
Peut-être, en effet. Voir même des exceptions standard si leur sémantique correspond.
Le principe général de gestion des exceptions dans une appli, c'est:
1/ dans le code applicatif lui-même, ne gérer que les exceptions auquelle on s'attend ET qu'on peut effectivement gérer à ce niveau là - soit directement, soit via une interaction avec l'utilisateur - et surtout laisser les autres exceptions se propager.
2/ au "top-level" de l'appli, mettre un gestionnaire d'exception "attrape-tout" qui: - logue l'erreur d'une façon ou d'une autre (ça aide à débugger) - affiche un messsage d'erreur aussi user-friendly que possible - fait le ménage si possible - termine le programme si pas moyen de continuer.
Attention quand même au niveau de l'"attrape-tout" : il y a certaines exceptions qui _doivent_ impérativement être relancées. Par example, sys.exit() fonctionne en lançant une exception, typiquement, celle là, tu ne veux pas la faire passer à la trappe !-)
HTH
david hautbois a écrit :
Salut
Je bricole un peu en python/GTK.
Et il y a un truc avec lequel je ne suis pas super à l'aise : la
remontée des erreurs à l'utilisateur.
Depuis mon interface, j'appelle une fonction qui appelle un fonction qui
appelle une fonction.
Généralement ça ne dépasse pas 3-4 appels.
Si la fonction en bout de chaine rencontre une erreur, je galère un peu
à faire remonter l'erreur jusqu'à l'utilisateur.
dernièrement j'utilise la méthode :
soit je retourne le tuple (1, resultat) si ça se passe bien
soit je retourne (-1, message d'erreur) en cas d'erreur
Je ne trouve pas çe très élégant.
Effectivement. D'autant que Python est un peu plus évolué que ça - on a
les exceptions pour gérer ce genre de problème.
Je devrait peut être déclencher des exceptions personnalisées....
Peut-être, en effet. Voir même des exceptions standard si leur
sémantique correspond.
Le principe général de gestion des exceptions dans une appli, c'est:
1/ dans le code applicatif lui-même, ne gérer que les exceptions
auquelle on s'attend ET qu'on peut effectivement gérer à ce niveau là -
soit directement, soit via une interaction avec l'utilisateur - et
surtout laisser les autres exceptions se propager.
2/ au "top-level" de l'appli, mettre un gestionnaire d'exception
"attrape-tout" qui:
- logue l'erreur d'une façon ou d'une autre (ça aide à débugger)
- affiche un messsage d'erreur aussi user-friendly que possible
- fait le ménage si possible
- termine le programme si pas moyen de continuer.
Attention quand même au niveau de l'"attrape-tout" : il y a certaines
exceptions qui _doivent_ impérativement être relancées. Par example,
sys.exit() fonctionne en lançant une exception, typiquement, celle là,
tu ne veux pas la faire passer à la trappe !-)
Salut Je bricole un peu en python/GTK. Et il y a un truc avec lequel je ne suis pas super à l'aise : la remontée des erreurs à l'utilisateur.
Depuis mon interface, j'appelle une fonction qui appelle un fonction qui appelle une fonction. Généralement ça ne dépasse pas 3-4 appels. Si la fonction en bout de chaine rencontre une erreur, je galère un peu à faire remonter l'erreur jusqu'à l'utilisateur.
dernièrement j'utilise la méthode : soit je retourne le tuple (1, resultat) si ça se passe bien soit je retourne (-1, message d'erreur) en cas d'erreur
Je ne trouve pas çe très élégant.
Effectivement. D'autant que Python est un peu plus évolué que ça - on a les exceptions pour gérer ce genre de problème.
Je devrait peut être déclencher des exceptions personnalisées....
Peut-être, en effet. Voir même des exceptions standard si leur sémantique correspond.
Le principe général de gestion des exceptions dans une appli, c'est:
1/ dans le code applicatif lui-même, ne gérer que les exceptions auquelle on s'attend ET qu'on peut effectivement gérer à ce niveau là - soit directement, soit via une interaction avec l'utilisateur - et surtout laisser les autres exceptions se propager.
2/ au "top-level" de l'appli, mettre un gestionnaire d'exception "attrape-tout" qui: - logue l'erreur d'une façon ou d'une autre (ça aide à débugger) - affiche un messsage d'erreur aussi user-friendly que possible - fait le ménage si possible - termine le programme si pas moyen de continuer.
Attention quand même au niveau de l'"attrape-tout" : il y a certaines exceptions qui _doivent_ impérativement être relancées. Par example, sys.exit() fonctionne en lançant une exception, typiquement, celle là, tu ne veux pas la faire passer à la trappe !-)
HTH
david hautbois
Super clair Merci.
Bruno Desthuilliers wrote:
david hautbois a écrit :
Salut Je bricole un peu en python/GTK. Et il y a un truc avec lequel je ne suis pas super à l'aise : la remontée des erreurs à l'utilisateur.
Depuis mon interface, j'appelle une fonction qui appelle un fonction qui appelle une fonction. Généralement ça ne dépasse pas 3-4 appels. Si la fonction en bout de chaine rencontre une erreur, je galère un peu à faire remonter l'erreur jusqu'à l'utilisateur.
dernièrement j'utilise la méthode : soit je retourne le tuple (1, resultat) si ça se passe bien soit je retourne (-1, message d'erreur) en cas d'erreur
Je ne trouve pas çe très élégant.
Effectivement. D'autant que Python est un peu plus évolué que ça - on a les exceptions pour gérer ce genre de problème.
Je devrait peut être déclencher des exceptions personnalisées....
Peut-être, en effet. Voir même des exceptions standard si leur sémantique correspond.
Le principe général de gestion des exceptions dans une appli, c'est:
1/ dans le code applicatif lui-même, ne gérer que les exceptions auquelle on s'attend ET qu'on peut effectivement gérer à ce niveau là - soit directement, soit via une interaction avec l'utilisateur - et surtout laisser les autres exceptions se propager.
2/ au "top-level" de l'appli, mettre un gestionnaire d'exception "attrape-tout" qui: - logue l'erreur d'une façon ou d'une autre (ça aide à débugger) - affiche un messsage d'erreur aussi user-friendly que possible - fait le ménage si possible - termine le programme si pas moyen de continuer.
Attention quand même au niveau de l'"attrape-tout" : il y a certaines exceptions qui _doivent_ impérativement être relancées. Par example, sys.exit() fonctionne en lançant une exception, typiquement, celle là, tu ne veux pas la faire passer à la trappe !-)
HTH
Super clair
Merci.
Bruno Desthuilliers wrote:
david hautbois a écrit :
Salut
Je bricole un peu en python/GTK.
Et il y a un truc avec lequel je ne suis pas super à l'aise : la
remontée des erreurs à l'utilisateur.
Depuis mon interface, j'appelle une fonction qui appelle un fonction
qui appelle une fonction.
Généralement ça ne dépasse pas 3-4 appels.
Si la fonction en bout de chaine rencontre une erreur, je galère un
peu à faire remonter l'erreur jusqu'à l'utilisateur.
dernièrement j'utilise la méthode :
soit je retourne le tuple (1, resultat) si ça se passe bien
soit je retourne (-1, message d'erreur) en cas d'erreur
Je ne trouve pas çe très élégant.
Effectivement. D'autant que Python est un peu plus évolué que ça - on a
les exceptions pour gérer ce genre de problème.
Je devrait peut être déclencher des exceptions personnalisées....
Peut-être, en effet. Voir même des exceptions standard si leur
sémantique correspond.
Le principe général de gestion des exceptions dans une appli, c'est:
1/ dans le code applicatif lui-même, ne gérer que les exceptions
auquelle on s'attend ET qu'on peut effectivement gérer à ce niveau là -
soit directement, soit via une interaction avec l'utilisateur - et
surtout laisser les autres exceptions se propager.
2/ au "top-level" de l'appli, mettre un gestionnaire d'exception
"attrape-tout" qui:
- logue l'erreur d'une façon ou d'une autre (ça aide à débugger)
- affiche un messsage d'erreur aussi user-friendly que possible
- fait le ménage si possible
- termine le programme si pas moyen de continuer.
Attention quand même au niveau de l'"attrape-tout" : il y a certaines
exceptions qui _doivent_ impérativement être relancées. Par example,
sys.exit() fonctionne en lançant une exception, typiquement, celle là,
tu ne veux pas la faire passer à la trappe !-)
Salut Je bricole un peu en python/GTK. Et il y a un truc avec lequel je ne suis pas super à l'aise : la remontée des erreurs à l'utilisateur.
Depuis mon interface, j'appelle une fonction qui appelle un fonction qui appelle une fonction. Généralement ça ne dépasse pas 3-4 appels. Si la fonction en bout de chaine rencontre une erreur, je galère un peu à faire remonter l'erreur jusqu'à l'utilisateur.
dernièrement j'utilise la méthode : soit je retourne le tuple (1, resultat) si ça se passe bien soit je retourne (-1, message d'erreur) en cas d'erreur
Je ne trouve pas çe très élégant.
Effectivement. D'autant que Python est un peu plus évolué que ça - on a les exceptions pour gérer ce genre de problème.
Je devrait peut être déclencher des exceptions personnalisées....
Peut-être, en effet. Voir même des exceptions standard si leur sémantique correspond.
Le principe général de gestion des exceptions dans une appli, c'est:
1/ dans le code applicatif lui-même, ne gérer que les exceptions auquelle on s'attend ET qu'on peut effectivement gérer à ce niveau là - soit directement, soit via une interaction avec l'utilisateur - et surtout laisser les autres exceptions se propager.
2/ au "top-level" de l'appli, mettre un gestionnaire d'exception "attrape-tout" qui: - logue l'erreur d'une façon ou d'une autre (ça aide à débugger) - affiche un messsage d'erreur aussi user-friendly que possible - fait le ménage si possible - termine le programme si pas moyen de continuer.
Attention quand même au niveau de l'"attrape-tout" : il y a certaines exceptions qui _doivent_ impérativement être relancées. Par example, sys.exit() fonctionne en lançant une exception, typiquement, celle là, tu ne veux pas la faire passer à la trappe !-)
