java - que - system.exit netbeans
Alternativas a System.exit(1) (8)
Creo que lanzar una excepción es lo que debes hacer cuando algo sale mal. De esta forma, si su aplicación no se ejecuta como una aplicación independiente, la persona que llama puede reaccionar ante ella y tiene alguna información sobre lo que salió mal. También es más fácil para la depuración porque también tiene una mejor idea de lo que salió mal cuando ve un seguimiento de la pila.
Una cosa importante a tener en cuenta es que cuando la excepción alcanza el nivel superior y por lo tanto hace que la VM se cierre, la VM devuelve un código de retorno de 1, por lo tanto, las aplicaciones externas que usan el código de retorno ven que algo salió mal.
El único caso donde creo que System.exit () tiene sentido es cuando su aplicación debe ser llamada por aplicaciones que no son Java y, por lo tanto, tiene que usar códigos de retorno para ver si su aplicación funcionó o no y quiere que esas aplicaciones tengan una oportunidad de reaccionar de manera diferente sobre diferentes cosas que van mal, es decir, necesita diferentes códigos de retorno.
Por varias razones, llamar a System.exit es mal visto al escribir aplicaciones Java , entonces, ¿cómo puedo notificar al proceso de llamadas que no todo va según lo previsto?
Editar: El 1 es un standin para cualquier código de salida distinto de cero.
El uso de System.exit está mal visto cuando la ''aplicación'' es realmente una sub-aplicación (por ejemplo, servlet, applet) de una aplicación Java (servidor) más grande: en este caso, System.exit podría detener la JVM y, por lo tanto, también todo otras sub-aplicaciones. En esta situación, arrojar una excepción apropiada, que podría ser capturada y manejada por el marco / servidor de aplicaciones es la mejor opción.
Si la aplicación Java realmente debe ejecutarse como una aplicación independiente, no hay nada de malo en usar System.exit . en este caso, establecer un valor de salida es probablemente la forma más fácil (y también la más utilizada) de comunicar la falla o el éxito al proceso principal.
Está mal visto por salidas normales . Si "no todo va según lo previsto", System.exit está bien.
Actualización: Debo añadir que asumo que su ''1'' tiene un significado que está documentado en alguna parte.
Estoy de acuerdo con la multitud de " tirar una excepción ". Una razón es que llamar a System.exit hace que el código sea difícil de usar si quieres que otro código pueda usarlo. Por ejemplo, si descubre que su clase sería útil desde una aplicación web, o algún tipo de aplicación que consume mensajes, sería bueno permitir que esos contenedores tengan la oportunidad de lidiar con la falla de alguna manera. Un contenedor puede querer volver a intentar la operación, decidir iniciar sesión e ignorar el problema, enviar un correo electrónico a un administrador, etc.
Una excepción a esto sería su método main() ; esto podría atrapar la Excepción y llamar a System.exit() con algún valor que pueda ser reconocido por el proceso de llamada o el script de shell.
La política de nuestra compañía es que está bien (incluso se prefiere) llamar a System.exit (-1), pero solo en los métodos init (). Definitivamente lo pensaría dos veces antes de llamarlo durante el flujo normal de un programa.
Lanzar excepciones es la mejor manera de enviar información sobre un cierto error hacia arriba y hacia afuera de la aplicación.
Un número no te dice tanto como:
Exception at thread ''main'': FileNotFoundException "The file ''foo'' doesn''t exist"
(O algo parecido a eso)
También puede ser peligroso / problemático en entornos de servlets web.
Lanzar una excepción generalmente se considera la otra alternativa.
System.exit() bloqueará y creará un interbloqueo si el subproceso que lo inició se utiliza en un enlace de cierre.