2010-01-15 43 views
11

Con respecto a C/C++ main() siempre debe devolver un número entero (cero para indicar el éxito y distinto de cero para indicar la falla). Puedo entender esto mientras se ejecuta el programa, se convierte en un proceso y cada proceso debe tener un estado de salida, que obtenemos haciendo echo $? de shell después de que el proceso se acaba.función principal no devuelve nada. ¿Por qué?

Ahora no entiendo por qué el método principal no devuelve nada en Java? ¿Tiene algo que ver con el hecho de que el programa se ejecuta en JVM y el proceso de JVM es reposicionable para devolver el estado de salida?

Por favor, aclare.

Gracias,
Roger

Respuesta

14

Si el método principal de una sola aplicación java roscado termina, la aplicación terminará con el código de salida 0. Si necesita otro código de salida, tal vez para indicar un error, se puede colocar

System.exit(yourNumberHere); 

en cualquier parte del código (especialmente fuera del método principal).

Esto es diferente para aplicaciones de subprocesos múltiples , en las que o bien tienen que utilizar System.exit desde el interior de kill -9 desde el exterior para detener la JVM.

Aquí está un ejemplo rápido, donde la terminación del principal no se detiene la aplicación (un típico servicio o comportamiento demonio):

public static void main(String args[]) { 
    Thread iWillSurvive = new Thread(new Runnable() { 
    public void run() { 
     while(true) { 
     // heat the CPU 
     } 
    } 
    }); 
    iWillSurvive.start(); 
} 

Observación: Claro, un hilo terminará cuando es el método run (o el método principal en el caso del hilo principal) termina. Y en este caso, cuando todos los hilos han terminado, la JVM terminará con el código de salida 0 (lo que nos lleva de vuelta a la pregunta inicial). Espero que todos estén felices ahora.

+0

Quiere decir que si no tengo un System.exit() en mi programa, JVM lo agregará con 0. Y si mi programa tiene una llamada explícita con un valor distinto de cero, se usará como salida estado? – gameover

+0

El proceso Java _no_ necesariamente finaliza si el método principal finaliza, por lo que (como señala kai1968) no es razonable devolver el código de salida del proceso del método principal. – jarnbjo

+0

Todavía está mal. No es necesario utilizar herramientas como kill o System.exit para detener una aplicación Java multiproceso. Sugerencia: Incluso la aplicación Java "Hello World" más sencilla tiene múltiples subprocesos (la VM Java inicia sus propios subprocesos para diferentes problemas de gestión) y se cierra cuando se realiza el método principal. – jarnbjo

7

Java tiene System.exit(int) para ese propósito.

Básicamente, un programa Java saldrá con el código de salida 0, si el flujo del programa llega al final del método principal (más o menos, se vuelve más raro con Swing y subprocesamiento, pero esto debería ser suficiente).

Si realiza una llamada a System.exit() en algún lugar (en cualquier lugar) o Runtime.getRuntime().exit() que es lo que System.exit() llama, el programa finaliza de forma inmediata y prematura.

Podría imaginarse que Java agregaría implícitamente System.exit(0) al final del método principal, pero puede haber diferencias más sutiles. Sin embargo, no tengo los detalles completos del cierre de JVM en mi cabeza en este momento.

+0

No escribimos eso al final de cada programa Java, ¿o sí? – gameover

+0

Si no desea regresar anormalmente, no. El código de salida implícito es '0', como de costumbre. – Joey

+0

Quiere decir que si no tengo un System.exit() en mi programa, JVM lo agregará con 0. Y si mi programa tiene una llamada explícita con un valor distinto de cero, se usará como salida estado? – codaddict

0

Posiblemente podría deberse a que System.exit(int exitCode) no devolvió ningún valor.

+0

No vi la publicación existente como respuesta, así que edité la publicación para que sea más una respuesta que una pregunta. –

16

Diseñado cuando multi-threading ya era una cosa común, dijo java (por diseño) "adiós" a la idea de que cuando se devuelve 'principal' se realiza el programa. Es por eso que no hay valor de retorno. Como dijeron los demás, use System.exit cuando quiera salir con el código de retorno.

+0

Eso es más o menos en pocas palabras. – McDowell

+0

+1 gran explicación :) – atv

4

Un pequeñísimo problema - en C++, no es necesario devolver nada del principal:

int main() { 
} 

es un programa perfectamente legal C++ - Actúa como si tuviera:

return 0; 

como la última declaración en main.

+0

Vine aquí para decir esto. Siempre me sorprende que, en este caso, la norma no requiera que usted vuelva inválido, y de hecho no puede declararlo de esa manera. Pero así es como funciona – jcoder

0

Sospecho que la razón de C/C++ que vuelve int es porque esa es la convención para indicar la función/método/programa éxito/falla en ese idioma.

Con la introducción de excepciones en Java, en lugar de cero para el éxito y valores distintos de cero para la falla, utiliza una jerarquía de excepción para fallas, y los éxitos fueron simplemente cuando no se lanzaron excepciones, eliminando así la necesidad de devolver un valor.

+0

Excepto que lanzar una excepción desde 'main()' no va a ser útil, y el único resultado debe ser un código de retorno. El hecho de que C no admita excepciones en un programa C y que Java lo haga en un programa Java no afecta su interacción con el sistema operativo. –

0

La mayoría de los programas que escribo estos días tienen algún tipo de interfaz de usuario y poco que puedan devolver de manera útil, y aún menos probable que cualquier cosa necesite ese código de estado.

Entonces, ¿por qué obligar a todos los programas a devolver uno? Como han dicho otros, puede devolver un código de estado si lo desea ...

+0

¿Qué fuerza a los programas a devolver un código de estado? –

1

El valor de salida es útil para secuencias de comandos como bash script o operaciones de línea de comando. Entonces en estos casos use System.exit().

Cuestiones relacionadas