Ce “standard” demande de retour/quitter les codes d'une demande de soutien?

Est-il une telle chose comme un ensemble standard de l'application des codes de retour? Des choses comme le retour à 0 pour la réussite 1 de l'échec, et puis ainsi de suite?

J'ai un Windows Server application que j'ai ajouté un peu de retour les codes d'erreur et voulait s'en tenir à des codes standard en plus de l'application spécifiques dont j'ai besoin.

InformationsquelleAutor MikeD | 2009-10-08
  1. 3

    Il n'y a pas une telle chose comme un ensemble de codes de sortie que les candidatures doivent se conformer.

    Cependant, il existe certaines communes, comme à 0 pour la réussite comme vous l'avez mentionné. Selon le Système d'Exploitation et les outils que vous utilisez, vous pouvez être en mesure de regarder les codes de sortie pour des applications similaires et de les imiter.

    • Alors que c'est un Windows question, je trouve qu'il est important de souligner que bien qu'il n'est pas dur standard (par exemple ISO ou DIN), il existe des conventions pour certains systèmes d'exploitation. E. g., ici sont les codes de sortie pour Linux: tldp.org/LDP/abs/html/exitcodes.html
    InformationsquelleAutor David
  2. 14

    Je pense que la seule norme est 0 en cas de réussite et non nulle en cas d'échec. Et c'est plus de la convention que de la norme.

    InformationsquelleAutor Douglas Leeder
  3. 7

    Peut-être que vous pouvez adopter certaines des conventions Unix.

    Dans une autre réponse, l'utilisateur David l'a suggéré

    sysexits.h a une liste des codes de sortie. Il semble remonter à au moins 1993 et certains gros projets comme Postfix l'utiliser, donc j'imagine que c'est le chemin à parcourir.

    De la OpenBSD homme page:

    Selon le style(9), il est préférable de ne pas appeler de sortie(3), avec des valeurs arbitraires pour indiquer une condition d'erreur lors de l'arrêt d'un programme. En place, la pré-défini codes de sortie de sysexits doit être utilisé, de sorte que l'appelant peut obtenir une estimation approximative de l'échec de la classe sans en regardant le code source.

    C'est la liste telle qu'elle apparaît sur un système Debian:

    #define EX_USAGE        64      /* command line usage error */
#define EX_DATAERR      65      /* data format error */
#define EX_NOINPUT      66      /* cannot open input */   
#define EX_NOUSER       67      /* addressee unknown */   
#define EX_NOHOST       68      /* host name unknown */
#define EX_UNAVAILABLE  69      /* service unavailable */
#define EX_SOFTWARE     70      /* internal software error */
#define EX_OSERR        71      /* system error (e.g., can't fork) */
#define EX_OSFILE       72      /* critical OS file missing */
#define EX_CANTCREAT    73      /* can't create (user) output file */
#define EX_IOERR        74      /* input/output error */
#define EX_TEMPFAIL     75      /* temp failure; user is invited to retry */
#define EX_PROTOCOL     76      /* remote error in protocol */
#define EX_NOPERM       77      /* permission denied */
#define EX_CONFIG       78      /* configuration error */

    À l'intérieur du fichier /usr/include/sysexits.h on peut trouver des descriptions plus détaillées de ces codes d'erreur.

    • C'est ce que j'utilise.
    InformationsquelleAutor gioele
  4. 6

    Le standard code d'état sont EXIT_SUCCESS et EXIT_FAILURE, défini dans stdlib.h. Pratiquement tout le monde utilise juste 0 et 1 respectivement, bien. Certains logiciels utilisent plusieurs non-zéro code pour les différents types d'erreurs.

    InformationsquelleAutor Laurence Gonsalves
  5. 4

    Codes de sortie sont loin de la norme, et sont plus utilisés pour le développeur, à savoir l'erreur approprié qui a eu lieu lors du retour de la demande. La norme de 0 en cas de réussite, non nulle de l'échec est une tendance générale, et est utilisé car il permet d'utiliser la totalité de la non-zéro pour toutes les erreurs possibles.

    Si votre application enregistre les erreurs de façon appropriée, le code de sortie sera probablement complètement inutile de garder une trace de.

    InformationsquelleAutor Will Eddins
  6. 1

    La seule vraie convention est que 0 signifie le succès et une valeur non-nulle (généralement 1) synonyme d'échec. Pour une référence officielle à ce sujet, voir, par exemple, de Microsoft C++ docs sur exit:

    Généralement, l'appelant définit la status de la valeur à 0 pour indiquer une sortie normale, ou de quelque autre valeur indique une erreur.

    Ou le C# docs sur Envrionnement.Exit et de l'Environnement.ExitCode qui diversement état:

    Utilisation de 0 (zéro) pour indiquer que le processus s'est achevé avec succès.

    et

    La valeur par défaut est 0 (zéro), ce qui indique que le processus s'est achevé avec succès.

    et

    Utiliser un nombre différent de zéro pour indiquer une erreur. Dans votre application, vous pouvez définir vos propres codes d'erreur dans une énumération, et retourner le code d'erreur approprié basé sur le scénario. Par exemple, le retour d'une valeur de 1 pour indiquer que le fichier n'est pas présent et une valeur de 2 indique que le fichier est dans un format incorrect. Pour une liste des codes de sortie utilisé par le système d'exploitation Windows, consultez Codes D'Erreur Du Système dans la documentation de Windows.

    Contrairement à certains autres answerers, je déconseille fortement d'utiliser le Codes d'Erreur du Système de l'application de codes de sortie. Quelques notes à propos de la Codes d'Erreur du Système:

    • Microsoft ne conseille pas de les utiliser comme application des codes de sortie n'importe où, et en effet explicitement suggèrent que vous "définir vos propres codes d'erreur" dans la documentation que je cite ci-dessus.
    • Microsoft ne les utilisent pas systématiquement comme des codes de sortie dans leur propre des demandes ou des commandes. Bien qu'il existe quelques exemples d'applications qui ne l'utilisation de ces codes, comme MsiExec.exe, il ya beaucoup plus que ne le font pas, comme dir, dotnet, ou De TAËF.
    • Leur utilisation semble manifestement mauvaise idée de moi. Il y a milliers de Système de Codes de Sortie, dont la plupart ne sont pas pertinentes, quel que soit votre application spécifique. Si vous essayez de les utiliser, vous allez déchets âges ramassé par le biais de la liste pour trouver des codes qui s'appliquent à votre scénario, et le résultat final sera moins utile pour un développeur d'appeler votre demande que si vous aviez défini un petit nombre de codes de sortie qui sont importantes pour votre application, - donc le faire à la place.
    • Ou tout simplement la cerise choisir quelques-uns qui sont utiles, et de la définir comme votre "propre" codes d'erreur qui se produisent à ré-utiliser les Codes d'Erreur du Système. Tant que votre programme a un comportement prévisible, personne ne se soucie vraiment de la mise en œuvre.
    InformationsquelleAutor Mark Amery
  7. 0

    Définitivement codes d'erreur standard défini pour Windows.

    Il y A longtemps, nous avons utilisé erreurs négatifs spécifiques de la "coutume" des erreurs, mais je doute que c'est une bonne pratique.

    Codes D'Erreur Du Système (Windows)

    • Vous n'avez pas besoin d'utiliser le Codes d'Erreur du Système en tant que programme les codes de sortie. Comme indiqué dans d'autres réponses ici, c'est classique pour les programmes de Windows pour utiliser 1 comme un fourre-tout code d'erreur; si tout le monde à l'aide de la Codes d'Erreur du Système, qui serait toujours dire "fonction Incorrecte" (et il n'y aurait aucun moyen d'indiquer un générique erreur non spécifiée).
    • C'est vrai, vous n'avez pas besoin de se conformer aux normes. La question était sur les normes, et c'est ce que j'ai donné. Le cas de base est de zéro indique un succès, non nulle indique un échec. Si l'appelant ne peut pas gérer les défaillances spécifiques, vous ne seriez pas attention à ce que l'erreur a été de toute façon, mais si vous vous attendez à ce que les appelants à l'action de l'échec, c'est une bonne pratique de donner significative des erreurs. Les normes aident à donner de la structure dans un tel cas.
    • "vous n'avez pas besoin de se conformer aux normes" - c'est un non sequitur, à l'aide de Codes d'Erreur du Système d'application des codes de sortie n'a rien de "se conformer à des normes", car il n'y a pas de standard, n'importe où, qui suggère de le faire. "si vous vous attendez à ce que les appelants à l'action de l'échec, c'est une bonne pratique de véritablement donner erreurs" - je suis d'accord, mais c'est mal réalisé par l'utilisation des Codes d'Erreur du Système comme il ya des milliers d'entre eux (si l'appelant ne peut pas les considérer tous) et ils sont susceptibles d'être trop générique pour décrire une application spécifique de l'erreur d'une manière significative.
    InformationsquelleAutor Pyro
  8. -2

    Mettre en œuvre ce que vous allez utiliser. Tout le reste est superflu.

    InformationsquelleAutor Stephane Grenier