Estado de salida distinto de cero para salida limpia

Depende del entorno, pero yo diría que es de estilo pobre.

Los sistemas similares a Unix tienen una fuerte convención de que un estado de salida de 0 denota éxito, y cualquier estado de salida que no sea cero denota un error. Algunos, pero no todos, los programas distinguen entre diferentes tipos de fallas con diferentes códigos de salida distintos de cero; por ejemplo, grep generalmente devuelve 0 si se encontró el patrón, 1 si no lo fue y 2 (o más) si hubo un error, como un archivo faltante.

Esta convención está bastante conectada a las carcasas de Unix. Por ejemplo, en sh , bash y otros shells de tipo Bourne, la instrucción if trata el estado de salida 0 como éxito / verdadero, y el estado de salida no cero como error / falso:

if your-command
then
    echo ok
else
    echo FAILURE
fi

Creo que las convenciones de MS Windows son similares.

Ciertamente, no hay nada que le impida escribir su propio programa que usa códigos de salida no convencionales, especialmente si nada más va a interactuar con él, pero tenga en cuenta que está violando una convención bien establecida, y podría vuelve y te morderá más tarde.

La forma habitual en que un programa devuelve este tipo de información es imprimirlo en stdout :

status = $(your-command)
echo Result is $status

Depende de lo que su entorno espera.

Mi favorito para wierdness, de Wikipedia :

  

En OpenVMS, el éxito se indica con valores impares y el fracaso con valores pares. El valor es un entero de 32 bits con subcampos: bits de control, número de instalación, número de mensaje y gravedad. Los valores de gravedad se dividen entre éxito (éxito, información) y fracaso (advertencia, error, fatal).

Creo que hay un precedente si el código de salida está devolviendo información significativa y relevante a la persona que llama y la definición de éxito no es realmente binaria. El precedente en el que estoy pensando es robocopy que devuelve un montón de cosas diferentes dependiendo de lo que sucedió .

Agregaré que siempre terminamos con un poco de depuración debido a esto: la mayoría de las utilidades asumen el código de salida 0 == éxito, así que aléjate cuando Robocopy devuelve 1 porque copió material no cero porque no copió material pero tampoco recibió un error.

no devolver 0 para una ejecución exitosa es una mala idea, ya que puede causar confusión para quienes ejecutan su programa. ¿Qué pasaría si algunos ejecutaran su programa más de 100 veces con diferentes entradas y quisieran saber cuántos fallaron o se completaron con éxito? Tener un solo valor de éxito hace que sea mucho más fácil detectar diferencias que tener muchos valores diferentes.

Si tiene un programa que tiene múltiples rutas de retorno exitosas que pueden significar cosas diferentes, yo diría que es una señal de que su programa está mal diseñado.

Sé de un caso que creo que es aceptable. Sé de un marco de prueba que se cierra con el número total de fallas de prueba. Entonces, por ejemplo, si el corredor de prueba completa sin pruebas fallidas, sale con cero. Si una prueba falló, aunque el corredor de prueba se ejecutó correctamente, sale con uno 1. Si fallan dos, devuelve 2, etc. Esto aumenta hasta 250, lo que significa "250 o más fallos de prueba".

Utiliza códigos de salida > 250 para indicar salidas anormales.

Aunque esto viola la convención, funciona bien en la práctica.

Realmente depende de lo que intenta transmitir con el código. DB2, por ejemplo, devuelve 100 si no se encuentran datos, otros valores positivos para advertencias y valores negativos para errores. Oracle hace algo similar.

Entonces, si hay diferentes estados de éxito, puede valer la pena usar valores de retorno variables.

CÓDIGOS DE SALIDA

• Un código de salida de 0 significa que había una actualización disponible, que se descargó e instaló correctamente si no se especificó --checkonly.
• Un código de salida de 1 significa que no hay actualizaciones nuevas disponibles.
• Un código de salida de 2 significa ...

En este caso, la salida 1 es simplemente un código informativo. Sin embargo, si hubiera escrito el código, no habría elegido 1 ya que generalmente falla en la red.