blocks|key|366271|text|当“应用程序”实际上是一个较大的System.exit应用程序(服务器)的子应用程序(例如，servlet、applet)时，就不能使用JVM+:在这种情况下，System.exit可以停止Java虚拟机，并因此停止所有其他的子应用程序。在这种情况下，抛出适当的异常是最好的选择，它可以由应用程序框架/服务器捕获和处理。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|366272|如果java应用程序真的打算作为一个独立的应用程序运行，那么使用System.exit也没什么错。在这种情况下，设置退出值可能是将失败或成功通知父进程的最简单(也是最常用的)方式。|366273|entityMap^0|G|B|28|B|0|W|B|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|R|8|@]|D|@]|E|$]]]|I|$]]

The use of <code>System.exit</code> is frowned upon when the 'application' is really a sub-application (e.g. servlet, applet) of a larger Java application (server): in this case the <code>System.exit</code> could stop the JVM and hence also all other sub-applications. In this situation, throwing an appropriate exception, which could be caught and handled by the application framework/server is the best option.

If the java application is really meant to be run as a standalone application, there is nothing wrong with using <code>System.exit</code>. in this case, setting an exit value is probably the easiest (and also most used) way of communicating failure or success to the parent process.

blocks|key|3161535|text|我同意“抛出一个异常”的观点。其中一个原因是，如果您希望其他代码能够使用您的代码，那么调用System.exit会使您的代码难以使用。例如，如果您发现您的类在web应用程序或某种消息消费应用程序中很有用，那么让这些容器有机会以某种方式处理失败将是很好的。容器可能想要重试该操作、决定记录并忽略该问题、向管理员发送电子邮件等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3161536|这方面的一个例外是您的main()方法；这可能会捕获异常，并使用调用进程或外壳脚本可以识别的值调用System.exit()。|offset|length|style|CODE|3161537|entityMap^0|0|B|6|1D|D|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]|$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|I|$]]

I agree with the "throw an Exception" crowd. One reason is that calling System.exit makes your code difficult to use if you want other code to be able to use it. For example, if you find out that your class would be useful from a web app, or some kind of message consuming app, it would be nice to allow those containers the opportunity to deal with the failure somehow. A container may want to retry the operation, decide to log and ignore the problem, send an email to an administrator, etc.

An exception to this would be your <code>main()</code> method; this could trap the Exception, and call <code>System.exit()</code> with some value that can be recognized by the calling process or shell script.

blocks|key|3374389|text|如果启动它的线程在关闭钩子中使用，System.exit()将阻塞并创建一个死锁。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3374390|entityMap^0|H|D|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

<code>System.exit()</code> will block, and create a deadlock if the thread that initiated it is used in a shutdown hook.

blocks|key|3161491|text|我们公司的政策是可以(甚至首选)调用System.exit(-1)，但只能在init()方法中调用。在程序的正常流程中调用它之前，我肯定会三思而后行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3161492|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Our company's policy is that it's OK (even preferred) to call System.exit(-1), but only in init() methods. I would definitely think twice before calling it during a program's normal flow.

blocks|key|364804|text|我认为当出现问题时，抛出异常是应该做的。这样，如果您的应用程序不是作为独立的应用程序运行，调用者可以对其做出反应，并获得有关哪里出了问题的一些信息。它也更容易用于调试目的，因为当您看到堆栈跟踪时，您还可以更好地了解哪里出了问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364805|需要注意的重要一点是，当异常到达顶层并因此导致VM退出时，VM将返回一个1的返回码，因此使用该返回码的外部应用程序会看到出现了错误。|364806|我认为System.exit()唯一有意义的情况是，当你的应用程序被非Java的应用程序调用时，因此必须使用返回代码来查看你的应用程序是否工作，并且你希望这些应用程序有机会对不同的错误做出不同的反应，即你需要不同的返回代码。|364807|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think throwing an exception is what you should do when something goes wrong. This way, if your application is not running as a stand-alone app the caller can react to it and has some information about what went wrong. It is also easier for debugging purposes because you as well get a better idea about what went wrong when you see a stack trace.

One important thing to note is that when the exception reaches the top level and therefore causes the VM to quit the VM returns a return code of 1, therefore outside applications that use the return code see that something went wrong.

The only case where I think System.exit() makes sense is when your app is meant to be called by applications which are not Java and therefore have to use return codes to see if your app worked or not and you want those applications to have a chance to react differently on different things going wrong, i.e. you need different return codes.

blocks|key|369607|text|在web+servlet环境中，这也可能是危险的/有问题的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|369608|抛出异常通常被认为是另一种选择。|369609|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It can be dangerous / problematic in web servlet environments also. 

Throwing an Exception is generally considered the other alternative.

blocks|key|366255|text|抛出异常是将有关某个错误的信息发送到应用程序中的最佳方式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|366256|数字并不能像下面这样告诉你：|366257|Exception+at+thread+'main':+FileNotFoundException+"The+file+'foo'+doesn't+exist"|code-block|syntax|javascript|366258|(或者类似的东西)|366259|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Throwing exceptions is the best way to send information about a certain error up and out of the app.

A number doesn't tell you as much as:

<pre><code>Exception at thread 'main': FileNotFoundException "The file 'foo' doesn't exist"
</code></pre>

(or something close to that)

blocks|key|3374285|text|对于正常的退出，它是不受欢迎的。如果“不是所有的事情都在按计划进行”，那么System.exit就没问题了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3374286|更新:我应该补充的是，我假设你的'1‘具有某处记录的含义。|3374287|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's frowned upon for normal exits. If "not everything is going according to plan", then System.exit is fine.

Update: I should add that I assume your '1' has meaning that is documented somewhere.

blocks|key|364865|text|我也觉得有必要加点盐。这是一个很好的问题，在我编写应用程序时总会出现这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364866|这里的每个人似乎都同意，你应该小心使用System.exit()，如果可能的话，使用异常。但是，System.exit()似乎仍然是向系统返回基本信息的唯一方法，因此，如果您想使应用程序可脚本化，就需要使用它。如果您不需要它，只需抛出一个异常并完成它。|offset|length|style|CODE|364867|但是如果(而且仅当)您的应用程序是单线程的，那么可以使用它--可以保证不会有其他东西进入，也不会打开任何资源(至少如果您始终使用try-with-resource习惯用法，我强烈建议您这样做，因为它还可以使代码更干净、更紧凑)。|364868|另一方面，一旦您的应用程序创建了可能写入资源的任何类型的线程，System.exit()就完全是“不，不”，因为它可能(并且随着时间的推移，它将)破坏数据。|364869|为了能够使用多线程和脚本化的应用程序，同时仍然保证数据的完整性，到目前为止，我最好的解决方案是保存您创建的任何修改资源的线程(例如，一致地使用将线程添加到列表中的工厂方法)，并安装一个关闭钩子，它通过中断和联接线程来干净地结束每个线程。由于关闭钩子也被System.exit()调用，这将保证(减去编程错误)在中间资源写入过程中没有线程被杀死。|364870|哦，是的，也许我甚至不应该提到它，但是:永远，永远，永远不要使用那个可怕的System.halt()方法。它只是射中VM的头部，而不调用任何关闭钩子。|364871|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html^0|0|J|D|1C|D|0|1S|H|0|0|0|3I|D|0|11|D|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@$D|Z|E|10|F|G]|$D|11|E|12|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|18|8|@$D|19|E|1A|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1B|8|@$D|1C|E|1D|F|G]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]]]

I feel impelled to add some salt of mine too. This is a great question that always pops up when I write an application.

As everyone here seems to agree, you should be careful using <code>System.exit()</code>, and if possible, use exceptions. However, <code>System.exit()</code> still seems the only way to return basic informations to the system, and thus required if you want to make your application scriptable. If you don't need that, just throw an exception and be done with it.

But if (and only if) your application is single-threaded, then it's fine to use it -- it's guaranteed that no other stuff is going in, and no resources are open (at least if you consistently use the <a href="https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html" rel="nofollow noreferrer">try-with-resource</a> idiom, which I'd highly recommend as it also makes the code cleaner and more compact).

On the other hand, as soon as your application creates any kind of thread that may write resources, System.exit() is a total "no, no", because it can (and, with time, will) corrupt data.

To be able to use a multi-threaded and scripted application and still guarantee the data integrity, my best solution so far is to save any resource-modifying thread you create (for example by consistently using a factory method which adds the thread to the list), and also installing a shutdown hook that cleanly ends each thread by interrupting and joining it. As the shutdown hook is also called by <code>System.exit()</code>, this will guarantee (minus programming errors) that no thread is killed in mid-resource writing.

Oh yes, maybe I shouldn't even mention it, but: never, EVER, use that horrible <code>System.halt()</code> method. It just shoots the VM in the head and doesn't call any shutdown hook.

For various reasons calling <code>System.exit</code> is frowned upon when writing Java Applications, so how can I notify the calling process that not everything is going according to plan?

Edit: The 1 is a <code>standin</code> for any non-zero exit code.

Alternatives to System.exit(1)

由于各种原因，在编写Java应用程序时，调用System.exit是不受欢迎的，那么我如何通知调用进程并不是一切都按计划进行呢？编辑：1是任何非零退出代码的standin。

问System.exit的替代方案(1)
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问System.exit的替代方案(1)EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问System.exit的替代方案(1)
EN