IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Python Discussion :

Convention du code de retour.


Sujet :

Python

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2012
    Messages : 11
    Points : 7
    Points
    7
    Par défaut Convention du code de retour.
    Je suis actuellement en plein conflit intérieur et extérieur (avec mon prof de prog.). J'ai fait des recherches mais soit j'suis pas chanceux, soit j'suis totalement débile. En tout cas, j'trouve rien :<

    Mon problème ? J'voudrais simplement savoir... Quand on exécute une fonction qui envoie un code de retour, dans ma réflexion, si tout s'est bien déroulé, la fonction fait un return 0 (ou False quoi), et si une erreur a été interceptée, un return 1 (donc True) serait envoyé.
    Ne me parlez pas des raise, svp. Restons dans ce sujet bien précis

    Je trouve ça logique, en fait. Alors mon "rival" pour ainsi dire m'explique que je dois mettre 1 au lieu de 0 car, par exemple, if(a == a): renverra True, donc 1.

    Heu ouais, ça me convaincs absolument pas. DONC. Est-ce qu'il existe une convention ou pas ? J'ai fait des recherches sur Google, je n'ai rien trouvé de bien. J'en ai fait dans les fichiers de Python et là par contre je tombe sur 2-3 trucs qui confirment ce que je pensais de base, cependant ça peut tout aussi bien être un hasard.

    codecs.h ~ L149 - 154 (de Python3.2)
    /* Register the error handling callback function error under the given
    name. This function will be called by the codec when it encounters
    unencodable characters/undecodable bytes and doesn't know the
    callback name, when name is specified as the error parameter
    in the call to the encode/decode function.
    Return 0 on success, -1 on error */
    Qu'en pensez-vous ? :3

  2. #2
    Membre habitué
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    114
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 114
    Points : 129
    Points
    129
    Par défaut
    Bonjour

    Il n'y a pas de convention acceptée par tous sur ce sujet.

    Il y a une habitude unix : valeur positive pour un bon déroulement, -1 pour une erreur.

    Ce genre de convention est en général décidée au niveau du projet ou de l'équipe. En prenant en compte du contexte exact du projet, on trouve souvent une solution assez élégante. Mais il s'agit surtout d'une convention : c'est à dire que la plus important soit que le point de vu soit partagé par toute l'équipe et qu'il soit adopté.
    Dans ces cas, je m'attache à toujours remonter le maximum d'information, sans surcout de ressources. Ainsi j'aime bien la convention : valeur positive pour un bon déroulement, valeur négative pour une erreur. Ensuite, la valeur négative change en fonction du type d'erreur.


    Cordialement
    Emmanuel

  3. #3
    Membre expérimenté
    Profil pro
    Développeur en systèmes embarqués retraité
    Inscrit en
    Mars 2006
    Messages
    946
    Détails du profil
    Informations personnelles :
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2006
    Messages : 946
    Points : 1 351
    Points
    1 351
    Par défaut
    Salut,

    C'est celui qui écrit la fonction qui décide de ce qu'elle doit retourner et qui doit bien sûr le documenter. Ça peut être un flag: 0 ou différent de zéro, un entier: 0 signifiant dans ce cas succès et différent de zéro donnant le code d'erreur. D'un autre côté, une fonction "isDigit" indiquant qu'un caractère fait partie de "0123456789" devrait logiquement retourner un zéro quand le test n'est pas concluant. Du coup, on comprend facilement des bouts de code comme:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    if (isDigit(mychar))
    {
        /* traitement pour les caracteree 0123456789 */ 
    }
    else
    {
        /* traitement pour les autres caracteres */
    }
    Pour ce qui est des OS, je ne connais que windows, et les programmes retournent des entiers signés à l'OS, 0 signifiant succès et une valeur différente de 0 étant le code d'erreur.

    A+

    Pfeuh

  4. #4
    Membre expérimenté Avatar de plxpy
    Homme Profil pro
    Ingénieur géographe
    Inscrit en
    Janvier 2009
    Messages
    792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur géographe
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Janvier 2009
    Messages : 792
    Points : 1 481
    Points
    1 481
    Par défaut
    Soyons précis (mais ici, tout est affaire de précision) :

    Il y a une habitude unix : valeur positive pour un bon déroulement, -1 pour une erreur.
    Je lis Unix (et pas C sous Unix), je comprends donc shell / interpréteur. Non, les codes retour sous le shell ne sont pas signés. Aucune chance de donner une quelconque signification à un code retour négatif qui ne sera jamais retourné, même quand on l'écrit explicitement :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    plx@sony:~$ more shell_script.sh 
    exit -1
    plx@sony:~$ chmod +x shell_script.sh 
    plx@sony:~$ 
    plx@sony:~$ ./shell_script.sh 
    plx@sony:~$ echo $?
    255
    plx@sony:~$
    Cela dit, 0 sous Unix est "conventionnellement" synonyme de "tout s'est bien passé". Quand il faut préciser des erreurs (ou de simples impossibilités de lancer le traitement), on n'a que des valeurs positives pour faire le distingo
    "La simplicité ne précède pas la complexité, elle la suit." - Alan J. Perlis
    DVP ? Pensez aux cours et tutos, ainsi qu'à la FAQ !

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 239
    Points : 36 692
    Points
    36 692
    Par défaut
    Salut,

    Citation Envoyé par Lyyn- Voir le message
    Quand on exécute une fonction qui envoie un code de retour, dans ma réflexion, si tout s'est bien déroulé, la fonction fait un return 0 (ou False quoi), et si une erreur a été interceptée, un return 1 (donc True) serait envoyé.
    Ne me parlez pas des raise, svp. Restons dans ce sujet bien précis
    Ne pas parler des exceptions, c'est ignorer l'apport de la POO sur le sujet.
    Un de ses apports est justement de ne plus avoir à définir et documenter ce genre de standard ni de faire la police pour s'assurer que les développeurs le respectent.
    Les développeurs peuvent donc omettre de tester les statuts de retour et laisser l'application se vautrer avec un minimum de diagnostic.
    Plus besoin de remonter à la cause de la cause de la cause: le glandu qui a omis de tester le code de retour de l'appel à la lecture de la socket et rempli la BDD avec des enregistrements corrompus.
    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  6. #6
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Mars 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2012
    Messages : 11
    Points : 7
    Points
    7
    Par défaut
    Citation Envoyé par pfeuh Voir le message
    Salut,

    C'est celui qui écrit la fonction qui décide de ce qu'elle doit retourner et qui doit bien sûr le documenter. Ça peut être un flag: 0 ou différent de zéro, un entier: 0 signifiant dans ce cas succès et différent de zéro donnant le code d'erreur. D'un autre côté, une fonction "isDigit" indiquant qu'un caractère fait partie de "0123456789" devrait logiquement retourner un zéro quand le test n'est pas concluant. Du coup, on comprend facilement des bouts de code comme:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    if (isDigit(mychar))
    {
        /* traitement pour les caracteree 0123456789 */ 
    }
    else
    {
        /* traitement pour les autres caracteres */
    }
    Pour ce qui est des OS, je ne connais que windows, et les programmes retournent des entiers signés à l'OS, 0 signifiant succès et une valeur différente de 0 étant le code d'erreur.

    A+

    Pfeuh
    Ouais, c'est un peu dans cet ordre d'idée que je me range aussi... Par contre je trouve ça étonnant qu'il n'existe pas de convention à ce niveau :p

    Merci beaucoup pour vos réponses !

    @wiztricks: Dans le cadre de l'enseignement, on ne parle pas directement de la POO, des raise, assert etc. On commence simple, donc on passe forcément par l'étape des codes de retour. C'est pourquoi j'ai demandé d'éviter de parler de ça, on risque de s'égarer inutilement :p

    Mais je suis tout à fait d'accord avec toi sinon

  7. #7
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 239
    Points : 36 692
    Points
    36 692
    Par défaut
    Salut,

    Citation Envoyé par Lyyn- Voir le message
    Ouais, c'est un peu dans cet ordre d'idée que je me range aussi... Par contre je trouve ça étonnant qu'il n'existe pas de convention à ce niveau :p
    A partir du moment ou le langage propose des exceptions, une telle convention est inutile: voilà qui devrait vous étonner.

    Ceci dit votre collègue a raison: si on doit interpréter le statut de retour d'une fonction comme un booléen (True/False), il est logique et préférable de traduire OK par True et KO par False.
    D'autant qu'en Python une fonction retournera par défaut None qui sera aussi évalué False: "if func()" sera moins ambigu côté OK qu'un "if not func()".

    La ou çà coince, c'est que la programmation est un ensemble de pratiques construites à partir de nécessités en décalage avec la logique et le bon sens.
    La nécessité est que l'appelant voudra aussi récupérer un indicateur en cas de retour KO pour afficher ou gérer l'erreur.
    Si la fonction ne retourne qu'un booléen, il faudra que l'appelé puisse récupérer cet indicateur via un autre canal: par exemple une variable globale comme le propose errno dans le cas de la libc.

    Une simplification est de décréter qu'une fonction retournera un code d'erreur. Ce code sera généralement un symbole EXIT_SUCCESS, EXIT_FAILURE, EACCES, ... Ce qui oblige l'appelant à récupérer la définition de ces symboles pour les utiliser et non de tester directement leur valeur.
    Mais obtenir des programmeurs qu'ils bossent proprement est coûteux.
    Rendre équivalent "OK <=> False <=> 0" permettra de réduire les omissions du test élémentaire plus aisément.

    Impossible de faire "convention" voire un "standard" une telle accumulation de mauvaises pratiques! D'autant que les multiples dimensions de ce "problème" sont résolues par les mécanismes d'exception disponibles, dans la plupart des langages, depuis plus de 30 ans.

    Dans le cadre de l'enseignement, on ne parle pas directement de la POO, des raise, assert etc. On commence simple, donc on passe forcément par l'étape des codes de retour. C'est pourquoi j'ai demandé d'éviter de parler de ça, on risque de s'égarer inutilement
    Une fonction est semblable à une fonction mathématique: elle retourne un résultat suivant la valeur des paramètres passés. Elle n'ont pas d'état: mêmes valeurs en entrées même résultat en sortie.
    Les fonctions add, sum, factorielle sont simple à écrire et à composer: - écrire = add(add(2,3), 4).

    Un statut de retour est rarement un résultat. Pour le récupérer, il faudra passer par des variables globales. Cette dépendance entre la fonction et des variables globales ne la rend plus "simple": comment allez vous composer de telles fonctions?

    De plus éviter de parler des exceptions en utilisant un langage comme Python: elles devront être comprises et gérées assez vite. ET vous n'êtes pas obligé d'ouvrir la boîte POO pour en parler.

    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

Discussions similaires

  1. Convention sur les codes de retour des scripts
    Par NewTone dans le forum Linux
    Réponses: 0
    Dernier message: 19/11/2009, 01h54
  2. [Mail] codes de retour email
    Par drommk dans le forum Langage
    Réponses: 8
    Dernier message: 26/06/2006, 15h53
  3. sqlldr code de retour 137
    Par thunderblade dans le forum Oracle
    Réponses: 9
    Dernier message: 18/04/2006, 14h55
  4. DELPHI6, Programme console et code de retour
    Par Desraux dans le forum Débuter
    Réponses: 2
    Dernier message: 21/07/2005, 09h15
  5. [Debutant(e)] Code de retour de mon programme
    Par benji999 dans le forum Général Java
    Réponses: 2
    Dernier message: 10/12/2004, 14h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo