Alternatives à System.exit(1)

Question

Pour diverses raisons, j'appelle System.exit est mal vu lorsqu'on écrit Applications Java, alors comment puis-je informer le processus d'appel que tout ne se passe pas comme prévu ?

Modifier: Le 1 est un standin pour tout code de sortie non nul.

Answer 1

L'utilisation de System.exit est mal vu lorsque «l'application» est en réalité une sous-application (par ex.servlet, applet) d'une application Java plus grande (serveur) :dans ce cas le System.exit pourrait arrêter la JVM et donc également toutes les autres sous-applications.Dans cette situation, la meilleure option est de lancer une exception appropriée, qui pourrait être interceptée et gérée par le framework/le serveur d'application.

Si l'application Java est réellement destinée à être exécutée en tant qu'application autonome, il n'y a rien de mal à utiliser System.exit.dans ce cas, définir une valeur de sortie est probablement le moyen le plus simple (et aussi le plus utilisé) de communiquer l'échec ou le succès au processus parent.

Answer 2

Je suis d'accord avec le "lancer une exception" foule.L'une des raisons est que l'appel de System.exit rend votre code difficile à utiliser si vous souhaitez qu'un autre code puisse l'utiliser.Par exemple, si vous découvrez que votre classe serait utile à partir d'une application Web ou d'une sorte d'application consommant des messages, il serait bien de permettre à ces conteneurs la possibilité de gérer l'échec d'une manière ou d'une autre.Un conteneur peut vouloir réessayer l'opération, décider de se connecter et d'ignorer le problème, envoyer un email à un administrateur, etc.

Une exception à cela serait votre main() méthode;cela pourrait piéger l'exception et appeler System.exit() avec une valeur qui peut être reconnue par le processus appelant ou le script shell.

Answer 3

System.exit() bloquera et créera une impasse si le thread qui l'a initié est utilisé dans un hook d'arrêt.

Answer 4

Cela peut également être dangereux/problématique dans les environnements de servlets Web.

Lancer une exception est généralement considérée comme l'autre alternative.

Answer 5

La politique de notre entreprise est qu'il est acceptable (voire préférable) d'appeler System.exit(-1), mais uniquement dans les méthodes init().J'y réfléchirais certainement à deux fois avant de l'appeler pendant le déroulement normal d'un programme.

Answer 6

Lancer des exceptions est le meilleur moyen d'envoyer des informations sur une certaine erreur vers le haut et hors de l'application.

Un chiffre ne vous dit pas grand-chose comme :

Exception at thread 'main': FileNotFoundException "The file 'foo' doesn't exist"

(Ou quelque chose proche de cela)

Answer 7

C'est mal vu pour normale sorties.Si "tout ne se passe pas comme prévu", alors System.exit convient.

Mise à jour:Je dois ajouter que je suppose que votre « 1 » a une signification documentée quelque part.

Answer 8

Je pense que lancer une exception est ce que vous devriez faire lorsque quelque chose ne va pas.De cette façon, si votre application ne s'exécute pas en tant qu'application autonome, l'appelant peut y réagir et dispose d'informations sur ce qui ne va pas.C'est également plus facile à des fins de débogage, car vous avez également une meilleure idée de ce qui n'a pas fonctionné lorsque vous voyez une trace de pile.

Une chose importante à noter est que lorsque l'exception atteint le niveau supérieur et provoque donc la fermeture de la VM, la VM renvoie un code retour de 1, donc les applications extérieures qui utilisent le code retour voient que quelque chose s'est mal passé.

Le seul cas où je pense que System.exit() a du sens est lorsque votre application est censée être appelée par des applications qui ne sont pas Java et doit donc utiliser des codes de retour pour voir si votre application a fonctionné ou non et que vous souhaitez que ces applications aient une chance de réagir différemment aux différentes choses qui ne vont pas, c'est-à-direvous avez besoin de codes de retour différents.